Open Stack

I agree about not needing extra identity information outside of the user's UUID, but what about the role/project/domain information stored in the PKI token? Does it remain or go away?

From: Morgan Fainberg [mailto:m at metacloud.com]
Sent: Thursday, February 27, 2014 12:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][keystone] Increase of USER_ID length maximum from 64 to 255



On Thursday, February 27, 2014, Dolph Mathews <dolph.mathews at gmail.com<mailto:dolph.mathews at gmail.com>> wrote:

On Thu, Feb 27, 2014 at 11:52 AM, Jay Pipes <jaypipes at gmail.com<javascript:_e(%7B%7D,'cvml','jaypipes at gmail.com');>> wrote:
On Thu, 2014-02-27 at 16:13 +0000, Henry Nash wrote:
> So a couple of things about this:
>
>
> 1) Today (and also true for Grizzly and Havana), the user can chose
> what LDAP attribute should be returned as the user or group ID.  So it
> is NOT a safe assumption today (ignoring any support for
> domain-specific LDAP support) that the format of a user or group ID is
> a 32 char UUID.  Quite often, I would think, that email address would
> be chosen by a cloud provider as the LDAP id field, by default we use
> the CN.  Since we really don't want to ever change the user or group
> ID we have given out from keystone for a particular entity, this means
> we need to update nova (or anything else) that has made a 32 char
> assumption.
I don't believe this is correct. Keystone is the service that deals with
authentication. As such, Keystone should be the one and only one service
that should have any need whatsoever to need to understand a non-UUID
value for a user ID. The only value that should ever be communicated
*from* Keystone should be the UUID value of the user.

+++


If the Keystone service uses LDAP or federation for alternative
authentication schemes, then Keystone should have a mapping table that
translates those elongated and non-UUID identifiers values (email
addresses, LDAP CNs, etc) into the UUID value that is then communicated
to all other OpenStack services.

I'd take it one step further and say that at some point, keystone should stop leaking identity details such as user name / ID into OpenStack (they shouldn't appear in tokens, and shouldn't be expected output of auth_token). The use cases that "require" them are weak and would be better served by pure multitenant RBAC, ABAC, etc. There are a lot of blockers to making this happen (including a few in keystone's own API), but still food for thought.

++ this would be a great change!

I am on the same page as Dolph when it comes to approving of the UUID being the only value communicated outside of keystone. There is just no good reason to send out extra identity information (it isn't needed and can help to reduce token bloat etc).

--Morgan

Sent via mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140227/dd6af2b1/attachment.html>