[rabbitmq-discuss] two factor authentication with tokens
0x6e6562 at gmail.com
Tue Jan 15 10:31:27 GMT 2013
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss