<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 27, 2014 at 11:52 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-02-27 at 16:13 +0000, Henry Nash wrote:<br>
> So a couple of things about this:<br>
><br>
><br>
> 1) Today (and also true for Grizzly and Havana), the user can chose<br>
> what LDAP attribute should be returned as the user or group ID. So it<br>
> is NOT a safe assumption today (ignoring any support for<br>
> domain-specific LDAP support) that the format of a user or group ID is<br>
> a 32 char UUID. Quite often, I would think, that email address would<br>
> be chosen by a cloud provider as the LDAP id field, by default we use<br>
> the CN. Since we really don't want to ever change the user or group<br>
> ID we have given out from keystone for a particular entity, this means<br>
> we need to update nova (or anything else) that has made a 32 char<br>
> assumption.<br>
<br>
</div>I don't believe this is correct. Keystone is the service that deals with<br>
authentication. As such, Keystone should be the one and only one service<br>
that should have any need whatsoever to need to understand a non-UUID<br>
value for a user ID. The only value that should ever be communicated<br>
*from* Keystone should be the UUID value of the user.<br></blockquote><div><br></div><div>+++</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If the Keystone service uses LDAP or federation for alternative<br>
authentication schemes, then Keystone should have a mapping table that<br>
translates those elongated and non-UUID identifiers values (email<br>
addresses, LDAP CNs, etc) into the UUID value that is then communicated<br>
to all other OpenStack services.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
> 2) In oder to support the ability for service providers to be able to<br>
> have the identity part of keystone be satisfied by a customer LDAP<br>
> (i.e. for a given domain, have a specific LDAP), then, as has been<br>
> stated, we need to subsequently, when handed an API call with just a<br>
> user or group ID, be able to "route" this call to the correct LDAP.<br>
> Trying to keep true to the openstack design principles, we had<br>
> planned to encode a domain identifier into the user or group ID - i.e.<br>
> distribute the data to where it is needed, in ortherwords, the user<br>
> and group ID provide all the info we need to route the call to the<br>
> right place. Two implementations come to mind:<br>
> 2a) Simply concatenate the user/group ID with the domain_id, plus some<br>
> separator and make a composite public facing ID. e.g.<br>
> "user_entity_id@@UUID_of_domain". This would have a technical maximum<br>
> size of 64+2+64 (i.e. 130), although in reality since we control<br>
> domain_id and we know it is always 32 char UUID - in fact the max size<br>
> would be 98. This has the problem of increasing the size of the<br>
> public facing field beyond the existing 64. This is what we had<br>
> planned for IceHouse - and is currently in review.<br>
> 2b) Use a similar concatenation idea as 2a), but limit the total size<br>
> to the existing 64. Since we control domain_id, we could (internally<br>
> and not visibly to the outside world), create a domain_index, that was<br>
> used in place of domain_id in the publicly visible field, to minimize<br>
> the number of chars it requires. So the public facing composite ID<br>
> might be something like <up to 54 chars of entity_id>@@<8 chars of<br>
> domain_index>. There is a chance, of course, that the 54 char<br>
> restriction might be problematic for LDAP users....but I doubt it. We<br>
> would make that a restriction and if it really became a problem, we<br>
> could consider a field size increase at a later release<br>
> 3) The alternative to 2a and 2b is to have, as had been suggested, an<br>
> internal mapping table that maps external facing entity_ids to a<br>
> domain plus local entity ID. The problem with this idea is that:<br>
> - This could become a very big table (you will essentially have an<br>
> entry for every user in every corporate LDAP that has accessed a given<br>
> openstack)<br>
> - Since most LDAPs are RO, we will never see deletes...so we won't<br>
> know when (without some kind of garbage collection) to cull entries<br>
> - It obviously does not solve 1) - since existing LDAP support can<br>
> break the 32 char limit - and so it isn't true that this mapping table<br>
> causes all public facing entity IDs to be simple 32 char UUIDs<br>
><br>
><br>
> From a delivery into IceHouse point of view any of the above are<br>
> possible, since the actual mapping used is relatively small part of<br>
> the patch. I personally favor 2b), since it is simple, has "less<br>
> moving parts" and does not change any external facing requirements for<br>
> storage of user and group IDs (above and beyond what is true today).<br>
><br>
><br>
> Henry<br>
> On 27 Feb 2014, at 03:46, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
><br>
> > On 02/26/2014 08:25 AM, Dolph Mathews wrote:<br>
> ><br>
> > ><br>
> > > On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
> > > wrote:<br>
> > > On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote:<br>
> > > > For purposes of supporting multiple backends for<br>
> > > Identity (multiple<br>
> > > > LDAP, mix of LDAP and SQL, federation, etc) Keystone is<br>
> > > planning to<br>
> > > > increase the maximum size of the USER_ID field from an<br>
> > > upper limit of<br>
> > > > 64 to an upper limit of 255. This change would not<br>
> > > impact any<br>
> > > > currently assigned USER_IDs (they would remain in the<br>
> > > old simple UUID<br>
> > > > format), however, new USER_IDs would be increased to<br>
> > > include the IDP<br>
> > > > identifier (e.g. USER_ID@@IDP_IDENTIFIER).<br>
> > ><br>
> > ><br>
> > > -1<br>
> > ><br>
> > > I think a better solution would be to have a simple<br>
> > > translation table<br>
> > > only in Keystone that would store this longer identifier<br>
> > > (for folks<br>
> > > using federation and/or LDAP) along with the Keystone user<br>
> > > UUID that is<br>
> > > used in foreign key relations and other mapping tables<br>
> > > through Keystone<br>
> > > and other projects.<br>
> > ><br>
> > ><br>
> > > Morgan and I talked this suggestion through last night and agreed<br>
> > > it's probably the best approach, and has the benefit of zero<br>
> > > impact on other services, which is something we're obviously<br>
> > > trying to avoid. I imagine it could be as simple as a user_id to<br>
> > > domain_id lookup table. All we really care about is "given a<br>
> > > globally unique user ID, which identity backend is the user from?"<br>
> > ><br>
> > ><br>
> > > On the downside, it would likely become bloated with unused<br>
> > > ephemeral user IDs, so we'll need enough metadata about the<br>
> > > mapping to implement a purging behavior down the line.<br>
> > UUIDs are 32 chars long. Its really just uuid@@uuid that pushes us<br>
> > over the 64 character limit.<br>
> > If we can shorten up the IDP_ID we can fit everything in 64 chars<br>
> > (which means only Nova needs to expand its column size)<br>
> ><br>
> > What if we enumerated IDPs by index, from 10000000 to 99999999 or<br>
> > something comparable, and then use the new domain_index (or prot<br>
> > domain id to not be a uuid). Then the above scheme would work and<br>
> > no migration would be required.<br>
> ><br>
> ><br>
> > ><br>
> > ><br>
> > > The only identifiers that would ever be communicated to<br>
> > > any non-Keystone<br>
> > > OpenStack endpoint would be the UUID user and tenant IDs.<br>
> > ><br>
> > > > There is the obvious concern that projects are utilizing<br>
> > > (and storing)<br>
> > > > the user_id in a field that cannot accommodate the<br>
> > > increased upper<br>
> > > > limit. Before this change is merged in, it is important<br>
> > > for the<br>
> > > > Keystone team to understand if there are any places that<br>
> > > would be<br>
> > > > overflowed by the increased size.<br>
> > ><br>
> > ><br>
> > > I would go so far as to say the user_id and tenant_id<br>
> > > fields should be<br>
> > > *reduced* in size to a fixed 16-char BINARY or 32-char<br>
> > > CHAR field for<br>
> > > performance reasons. Lengthening commonly-used and<br>
> > > frequently-joined<br>
> > > identifier fields is not a good option, IMO.<br>
> > ><br>
> > > Best,<br>
> > > -jay<br>
> > ><br>
> > > > The review that would implement this change in size<br>
> > > > is <a href="https://review.openstack.org/#/c/74214" target="_blank">https://review.openstack.org/#/c/74214</a> and is<br>
> > > actively being worked<br>
> > > > on/reviewed.<br>
> > > ><br>
> > > ><br>
> > > > I have already spoken with the Nova team, and a single<br>
> > > instance has<br>
> > > > been identified that would require a migration (that<br>
> > > will have a fix<br>
> > > > proposed for the I3 timeline).<br>
> > > ><br>
> > > ><br>
> > > > If there are any other known locations that would have<br>
> > > issues with an<br>
> > > > increased USER_ID size, or any concerns with this change<br>
> > > to USER_ID<br>
> > > > format, please respond so that the issues/concerns can<br>
> > > be addressed.<br>
> > > > Again, the plan is not to change current USER_IDs but<br>
> > > that new ones<br>
> > > > could be up to 255 characters in length.<br>
> > > ><br>
> > > ><br>
> > > > Cheers,<br>
> > > > Morgan Fainberg<br>
> > > > —<br>
> > > > Morgan Fainberg<br>
> > > > Principal Software Engineer<br>
> > > > Core Developer, Keystone<br>
> > > > <a href="mailto:m@metacloud.com">m@metacloud.com</a><br>
> > > ><br>
> > > ><br>
> > ><br>
> > > > _______________________________________________<br>
> > > > OpenStack-dev mailing list<br>
> > > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > > ><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>