Open Stack

As we get closer to the summit, I'd like to make sure we have resolution 
on one of the most critical issues in Keystone.  How to deal with users 
coming out of multiple data sources.

The issue is that a userid out of one domain must fill two requirements:

1. one userid cannot conflict with a userid from any other domain
2. we must be able to map from the userid back to the domain backend 
that issued it.

We are trying to avoid an approach where we shadow the LDAP or Federated 
identity provider data in a SQL backend specific to Keystone.  That kind 
of data duplication has a host of problems we would rather not have to 
address.  Instead, we need to come up with a way to layer on the User ID 
scheme on top of the data from LDAP.

I suspect the scheme is going to end up being something like:

user the same field for username an userid.

The actual userid value will be composed of two parts.  One will be the 
username from LDAP, the other will be assigned by Keystone based on the 
domain id.  The last instalment we had a suggestion that looked like:

ayoung@@redhat.

The @@ is to make sure we don;t trip over some place that decided to use 
email address, but still gives a separator character that is URL safe.

There is some concern with the length of the field.  Most of the 
services have userid as 64chars long, and we are pushing to syncronize 
all the projects on that length.  UUIDs ar 32 chars long, and Nova was 
the last to assume that as userid was a UUID.  Still, we can't go beyond 
the 64 char limit without some pain.

One question is whether we are stuck with requirement 2.  For example, 
if we said that a user login was always done with:  domain name and 
username, we would never have to look up a user by pure userid.

If we can loosen up on the "map userid back to domain" requirement, we 
can  get away with something more like  sha256("%s%S" %(username, 
domain_name))  for the userid.  This has the benefit of looking just 
like a UUID and fitting into the same size filed in the databases.

Resolving this issue is key to both Multiple LDAP and Federation.