[rabbitmq-discuss] X.509 client authentication

[Simon MacMullen]

On 06/01/11 14:36, Warren Smith wrote:
> Hi all,

Hi Warren.

> I’m investigating using RabbitMQ as part of a project and I’ve got a
> question about client authentication. Right now, the clients in this
> project (users, daemons, etc.) all have X.509 certificates. It would be
> very useful if these identities could be used for authentication and
> authorization in RabbitMQ.
>
> I found the SSL documentation for RabbitMQ and I’ve been working on
> configuring a RabbitMQ service to support SSL. However, it appears that
> even if the client program presents a certificate for authentication,
> this identity doesn’t seem to be used by RabbitMQ. The client still
> needs to present a username/password – this is what I’d like to avoid.
 >
> Is it currently possible to use the DN in the client certificate as the
> identity of the client?

Not in any current release.

However, we have been working on this recently and the next version will 
have a much expanded view of authentication / authorisation that will 
allow you to do this, using the SASL EXTERNAL authentication mechanism 
(which we take to mean "take the authenticated user as being the CN from 
the X509 certificate).

There will also be an authentication / authorisation backend plugin 
mechanism that will mean details of which users exist do not need to be 
stored in the internal Mnesia database.

This is all on the default branch today if you feel like building from 
source.

To use SASL EXTERNAL, support is needed in the clients. We've added it 
to the Java, .NET and Erlang clients, but if you're using a third party 
client it will need a (hopefully rather small) tweak.

For your needs, would you want to store the details of users and 
permissions in some database (either Mnesia or something like LDAP), or 
would you want your PKI to be the entire user database (which would 
require that all users have the same hard-coded permissions)? The former 
will definitely be possible with the next release, the latter would need 
some kind of null backend plugin which could probably be written fairly 
easily.

Cheers, Simon

-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware