[rabbitmq-discuss] X.509 client authentication

Fri Jan 7 11:43:49 GMT 2011

On 06/01/11 16:46, Warren Smith wrote:
> 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 have to admit I picked CNs for simplicity. The problem with DNs is 
that in general we assume that a username is a string, and can be 
matched as such. As soon as we start using DNs as usernames we have all 
sorts of problems with normalisation. I'm not a real X.509 expert, but 
it doesn't seem like there's a standard normalisation for DNs as 
strings. There are some conventions but they seem to get very hazy once 
you look at issues like escaping.

I'll have a look at how this could be made to work 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.

Hmm. The idea is that SASL EXTERNAL is just another way to authenticate, 
and so it provides a username. I'm not sure a DN-to-username mapping is 
the best way to proceed (suppose you're not storing users in Mnesia - do 
all auth backends need to support such a mapping?)

Cheers, Simon

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