On Wed, Feb 26, 2014 at 4:23 AM, Marco Fargetta <marco.farge...@ct.infn.it>wrote:
> Hi Morgan, > > On Tue, Feb 25, 2014 at 11:47:43AM -0800, Morgan Fainberg wrote: > > For purposes of supporting multiple backends for Identity (multiple > LDAP, mix > > of LDAP and SQL, federation, etc) Keystone is planning to increase the > maximum > > size of the USER_ID field from an upper limit of 64 to an upper limit of > 255. > > This change would not impact any currently assigned USER_IDs (they would > remain > > in the old simple UUID format), however, new USER_IDs would be increased > to > > include the IDP identifier (e.g. USER_ID@@IDP_IDENTIFIER). > > > > in this case if a user would access with different systems (e.g. SAML with > portal, LDAP with CLI) it is mapped to two different identities inside > keystone. > Is this correct? If so, is there any way to map an individual person with > two identities sharing resources? > That's correct - they'd result in different identities and keystone has no means of presuming they are the same "person." But I think you answered it yourself, in that they would effectively be sharing resources with themselves, so you'd just have to ensure they had the same authorization on the same projects using both identities. > > Cheers, > Marco > > > > There is the obvious concern that projects are utilizing (and storing) > the > > user_id in a field that cannot accommodate the increased upper limit. > Before > > this change is merged in, it is important for the Keystone team to > understand > > if there are any places that would be overflowed by the increased size. > > > > The review that would implement this change in size is https:// > > review.openstack.org/#/c/74214 and is actively being worked on/reviewed. > > > > I have already spoken with the Nova team, and a single instance has been > > identified that would require a migration (that will have a fix proposed > for > > the I3 timeline). > > > > If there are any other known locations that would have issues with an > increased > > USER_ID size, or any concerns with this change to USER_ID format, please > > respond so that the issues/concerns can be addressed. Again, the plan > is not > > to change current USER_IDs but that new ones could be up to 255 > characters in > > length. > > > > Cheers, > > Morgan Fainberg > > > > — > > Morgan Fainberg > > Principal Software Engineer > > Core Developer, Keystone > > m...@metacloud.com > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > -- > ==================================================== > Eng. Marco Fargetta, PhD > > Istituto Nazionale di Fisica Nucleare (INFN) > Catania, Italy > > EMail: marco.farge...@ct.infn.it > ==================================================== > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
