[rabbitmq-discuss] two factor authentication with tokens
0x6e6562 at gmail.com
Thu Jan 17 13:17:13 GMT 2013
On Thursday, 17 January 2013 at 11:20, Simon MacMullen wrote:
> 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.
Since I posted a number of times into this thread, I'm not sure which question you are answering here. My latest question was about the fact that I could encode the
(optional) radius token, depending on whether the specified vhost is subject to a extra token verification or not;
into the SASL payload and my custom rabbit_auth_mechanism would decode this, and decide based on the vhost supplied whether to perform a lookup on the token. All of this is up to this custom implementation.
What I don't understand about your observation may stem from my misunderstanding the flow of the handshake during AMQP connection establishment. I was assuming that due to the sequence of AMQP frames defined in the protocol, Rabbit would initially delegate the authentication to my custom rabbit_auth_mechanism, which could present vhost X. Once this callback has successfully done everything it needs to do and returns a user back to Rabbit, then the client would be able to send a connection.open frame. At this point, the client could potentially encode vhost Y into that frame, and hence effectively by-pass the logic of the custom rabbit_auth_mechanism.
Maybe I'm missing the point here.
Having said all of this, in the meantime I've come up with an alternative solution - just run separate Rabbit instances for each vhost.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss