Open Stack

On Thursday, February 27, 2014, Dolph Mathews <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/9ce45d49/attachment.html>