[rabbitmq-discuss] two factor authentication with tokens

[Simon MacMullen]

Yes, but that shouldn't be too problematic - while all our auth 
mechanisms invoke rabbit_access_control:check_user_pass_login/2 or 
similar (which ends up looking up and driving auth backends), you could 
write an auth mechanism which either drives an auth backend directly, or 
contains its own auth backend. Then it can do whatever it wants - the 
contract of an auth mechanism is to reject login or provide a user.

Cheers, Simon

On 15/01/13 10:31, Ben Hood wrote:
> Thinking about this a little further, what I am proposing with encoding
> a vhost based challenge in the SASL mechanism would then make the
> subsequent vhost authorization liable to be hi-jacked by a client that
> declares itself in the SASL challenge to want to access the low security
> (non-2FA vhost) and only supply 1FA, but then in the ConnectionOpen
> frame it could freely request to access the 2FA vhost.
>
> So maybe this conditional execution is not so cool from a security
> perspective, unless you somehow patch the whole handshake to prevent the
> vhost from being forged.
>
> On Tuesday, 15 January 2013 at 09:33, Ben Hood wrote:
>
>> In addition to the previous questions, is it possible to configure the
>> auth challenge on the broker side to be vhost specific? For example,
>> clients connecting to vhost 1 should be taken down the aforementioned
>> LDAP + Radius path, but clients connecting to vhost 2 can just be
>> authenticated with a plain LDAP lookup.
>>
>> Or does the SASL handshake occur before the client presents the target
>> vhost to the broker - in which case I presume you would have to
>> encapsulate this information into the custom SASL mechanism and
>> evaluate it selectively in the custom auth plugin that wraps Radius
>> and LDAP (as discussed previously)?
>>
>> On Friday, 11 January 2013 at 18:02, Jerry Kuch wrote:
>>
>>>
>>>
>>> On Fri, Jan 11, 2013 at 9:47 AM, Ben Hood <0x6e6562 at gmail.com
>>> <mailto:0x6e6562 at gmail.com>> wrote:
>>>>
>>>> Can this also be made to work in conjunction with an LDAP provider,
>>>> i.e. by chaining the supported LDAP backend with a custom backend to
>>>> additionally validate the the token? I wondering whether you can
>>>> require the client to answer both a username/password challenge
>>>> (evaluated by the supported LDAP auth backend) as well as having the
>>>> token checked by the the custom backend? Does the protocol and
>>>> wiring flow allow for the LDAP backend to get re-used in this way or
>>>> would you need to implement the custom backend that wraps the lookup
>>>> against the LDAP directory and the lookup against the Radius server?
>>>
>>> If I recall correctly, one backend or the other would have to know
>>> about the other one and take care of the chaining rather than
>>> something like this being possible in the Rabbit configuration.  The
>>> backend chosen to go with a given connection is basically the first
>>> one in the rabbitmq.config file's list of backends that succeeds as
>>> they're tried in order, and is bound irrevocably to that session
>>> thereafter.
>>>
>>> Pursuing this outcome you might be able to call into specific parts
>>> of the LDAP backend as helpers, but a good hunk of your hybrid auth
>>> logic would be in your plugin itself.
>>>
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
>>> <mailto:rabbitmq-discuss at lists.rabbitmq.com>
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>


-- 
Simon MacMullen
RabbitMQ, VMware