[rabbitmq-discuss] X.509 client authentication

Warren Smith wsmith at tacc.utexas.edu
Thu Jan 6 16:46:45 GMT 2011

Hi Simon,

Thanks for the quick response. I'll grab the latest source and see what I can do with it. One thing - you say CN, not DN. Is this customizable so that a DN can be used instead? We have enough users and accept more than one CA so it becomes possible that 2 people have the same CN (but different DNs). I don't expect to hit this for any of the use cases I want to support in the next year or so, though.

I've been using the Java client when trying out the SSL stuff so that should be fine. Ultimately I'd like to use a Python client.

I could handle storage of user details and authorization in a number of ways without any problems. I could store an external mapping of DN -> RabbitMQ username and then let RabbitMQ do its normal authorization against the username. I could store DNs and permissions externally and have RabbitMQ do authorization call outs. I'm sure there are other ways that would work fine, too. I do want different users to have different permissions, but doing this on a per-vhost level should be enough for me.

I think the main thing is how much you all want to integrate client DNs into the service vs a plugin. If you want it very integrated, DN->username mappings could be stored in the Mnesia and managed by rabbitmqctl. A user could then potentially have multiple DNs (we have this situation sometimes) and be able to authenticate using a DN or a username/password.



-----Original Message-----
From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon MacMullen
Sent: Thursday, January 06, 2011 8:56 AM
To: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] X.509 client authentication

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 

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 

Cheers, Simon

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

rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com

More information about the rabbitmq-discuss mailing list