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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
