Open Stack

On Wed, Feb 26, 2014 at 4:23 AM, Marco Fargetta
<Marco.Fargetta at 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 at metacloud.com
> >
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at 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.Fargetta at ct.infn.it
> ====================================================
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140226/308a60b5/attachment.html>