[rabbitmq-discuss] Pluggable Authentication back ends?

[Ben Hood]

Scott,

On Wed, Jun 16, 2010 at 5:32 PM, Scott Brooks <scott at beamdog.com> wrote:
> Yeah, when I was poking around I noticed that it's a pretty small
> number of places that it would change.
>
> I'll play around with it a bit and see what I come up with.

As Matthias pointed out, somebody who is using Rabbit asked LShift to
propose how Rabbit could be extended to provide the notion of
pluggable authentication. The use case they had in mind was to
delegate authentication to external directory server.

In conjunction with Matthias I've put together a statement of work
that outlines how this could be done, but as yet, I haven't heard any
feedback on the matter.

I shouldn't think that the details of the changes to Rabbit are a
state secret, so I guess I can paraphrase the essence of the proposal
here:

The high level mechanism involves a change to the behaviour of the
access control module in the RabbitMQ server. After this change has
been made, the flow of authentication will be as follows:

- An AMQP client will perform the standard protocol authentication challenge.
- RabbitMQ offers the client an AMQPLAIN SASL challenge, which
requires the client to provide a username and password.
- Should the supplied username match a user that is currently
configured in the RabbitMQ user database, then the authentication will
be performed against the credentials registered in the internal
database.
- Should the supplied username not match an internally configured
user, then the the access control module will delegate the
authentication to an external provider via an RPC over AMQP. If an
external provider responds positively to the username-password
challenge within a specified period of time, then the AMQP peer will
be considered to be authenticated for the duration of the connection
that the client maintains with the server.
- In all other cases the server will deny access to the client and
will terminate the handshake in a protocol compliant fashion.

There is also a low level detail implementation plan which was used to
come up with a development estimate, but as yet, the whole thing is
vaporware pending approval from the client.

Hope this is of some use to you,

Cheers,

Ben