[rabbitmq-discuss] X.509 client authentication

[James Casey]

On 7 January 2011 12:43, Simon MacMullen <simon at rabbitmq.com> wrote:
> 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.

Hi Simon,

what are the restrictions you have in usernames ?  Does it have to be
a non-whitespace string ?  Are there length restrictions ?

We're also in the situation where we have to accept 50-60 CAs (all
with different naming structures for the DN).  We implemented
something for activemq (where the username is just any Java string
that can be compared against).  Here we simply did standard URI
escaping to map into a username.  E.g for my DN:

'/DC=ch/DC=cern/OU=Organic Units/OU=Users/CN=jamesc/CN=380618/CN=James Casey'

I get a username of
 '%2FDC%3Dch%2FDC%3Dcern%2FOU%3DOrganic%20Units%2FOU%3DUsers%2FCN%3Djamesc%2FCN%3D380618%2FCN%3DJames%20Casey'
Since these are never entered directly by a user it's not such a big
problem that they are long.  Of course if you've no problems with
spaces, etc in a username you could just use the DN directly as the
username.


> 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 guess the 'standard' is what 'openssl x509 -subject' gives back.
Note that the java tools work differently (elements in reversed order
with comma separation instead of / separators.

>
> 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?)
>

I think this isn't such a good idea - it's tricky mapping multiple DNs
to the same 'user'.  Often a user has multiple DNs since he wants to
distinguish himself this way (an DN for admin access vs a DN for
normal access).  The issue I see here is what happens when a user gets
a new DN after an old one expired and the CA has a policy of
generating a new DN string (usually by appending a random number in a
CN field.  Normally you then need admin tools to change a username,
keeping the same permissions.

One question here on the implementation - with an external provider
it's only for authentication, right?  Authorization is still done by
storing permissions in Mnesia against users ?

cheers,

James.

> Cheers, Simon
>
> --
> Simon MacMullen
> Staff Engineer, RabbitMQ
> SpringSource, a division of VMware
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>