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