Open Stack

Somewhat surprised this got zero responses. Some comments inline from me.

On 04/15/2014 10:39 PM, Adam Young wrote:
> 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

Why is this the case? Or perhaps I am misunderstanding what you mean by 
"userid". To me, a userid is a unique identifier for the user within the 
Keystone system -- in other words, the UUID that is globally unique for 
the user. There may be many usernames in other domains that map to the 
same user UUID in a Keystone system. But only the UUID should ever 
"leave Keystone" -- i.e. be transmitted out of the auth_token middleware 
and end up in the other project databases.

> 2. we must be able to map from the userid back to the domain backend
> that issued it.

Yup, agreed. But Keystone should do this and only Keystone. I see no 
valid reason to leak domain and username information outside of Keystone.

> 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.

If you are talking about the above being the user ID that gets 
transmitted to other project endpoints, then -1 from me. If you are 
talking about the above being the format of a "user identifier" that 
gets passed to the Keystone auth_token middleware, then verified by 
Keystone and the real user UUID is then used by the other project 
endpoints, then I'm fine with that.

Also, I don't really understand why you need this to be URL-safe... 
Isn't this transferred as an HTTP header?

> 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.

I am a big -1 on expanding the length of the user ID fields in Nova or 
any other project's database. UUIDs should be the *only* thing stored in 
non-Keystone databases, and IMO, the only appropriate way forward is the 
following:

  1) Change the Keystone auth_token middleware to only return the user 
UUID value (once any mapping/translation has occurred)
  2) Design data migration scripts for any environment that has non-UUID 
values in the user ID fields in their databases and translate the 
non-UUID value to the UUID value
  3) Change the data storage for these types of fields to CHAR(32) or 
BINARY(16)

> 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.

Again, I'm 100% against having these things live outside of Keystone. 
Within Keystone, having whatever mapping system is needed is perfectly fine.

> 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.

-1. We have experienced the pain in Nova of having to map between 
internal UUIDs and non-UUID identifier values with the EC2 server 
identifiers. I'd much prefer any such translation of identifiers for the 
user and domain level be firmly behind Keystone's walls.

Best,
-jay

> Resolving this issue is key to both Multiple LDAP and Federation.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev