[rabbitmq-discuss] Pluggable Authentication back ends?

[Matthias Radestock]

Ben, thanks for outlining the plan. Just to clarify a few points for 
Scott ...

Ben Hood wrote:
> 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.

...which is unchanged from the current behaviour.

> - 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].

More precisely, the access control module will invoke a function on a 
pluggable authentication module. It's then up to that module to do 
whatever is required to perform the required authentication, such as the 
RPC-over-AMQP mechanism mentioned.

This keeps the required changes to the server to a minimum, and allows 
different authentication mechanisms to be supplied as plug-ins.

> 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.

Yep, that would all be handled by the rabbit-auth-over-amqp plug-in, 
rather than being part of the server core.


Regards,

Matthias.