[openstack-dev] Fwd: keystone federation user story
ayoung at redhat.com
Wed May 25 02:30:16 UTC 2016
On 05/24/2016 01:55 PM, Alexander Makarov wrote:
> here is an actual use case for shadow users assignments, let's discuss
> possible solutions: all suggestions are appreciated.
> ---------- Forwarded message ----------
> From: *Andrey Grebennikov* <agrebennikov at mirantis.com
> <mailto:agrebennikov at mirantis.com>>
> Date: Tue, May 24, 2016 at 9:43 AM
> Subject: keystone federation user story
> To: Alexander Makarov <amakarov at mirantis.com
> <mailto:amakarov at mirantis.com>>
> Main production usecase:
> As a system administrator I need to create assignments for federated
> users into the projects when the user has not authenticated for the
> first time.
> Two different approaches.
> 1. A user has to be assigned directly into the project with the role
> Role1. Since shadow users were implemented, Keystone database has the
> record of the user when the federated user authenticates for the first
> time. When it happens, the user gets unscoped token and Keystone
> registers the user in the database with generated ID (the result of
> hashing the name and the domain). At this point the user cannot get
> scoped token yet since the user has not been assigned to any project.
> Nonetheless there was a bug
> https://bugs.launchpad.net/keystone/+bug/1313956 which was abandoned,
> and the reporter says that currently it is possible to assign role in
> the project to non-existing user (API only, no CLI). It doesn't help
> much though since it is barely possible to predict the ID of the user
> if it doesn't exist yet.
> Potential solution - allow per-user project auto-creation. This will
> allow the user to get scoped token with a pre-defined role (should be
> either mentioned in config or in mapping) and execute operations right
What we discussed at the summit was the ability for some power user to
pre=-create the shadow user record by passing in the data that that
would be mapped:
Principal: ayoung at YOUNGLOGIC.NET
Another API will allow for query if a user exists.
> Disadvantages: less control and order (will potentially end up with
> infinite empty projects).
> Benefits: user is authorized right away.
> Another potential solution - clearly describe a possibility to assign
> shadow user to a project (client should generate the ID correctly),
> even though the user has not been authenticated for the first time yet.
> Disadvantages: high risk of administrator's mistake when typing user's ID.
> Benefits: user doesn't have to execute first dummy authentication in
> order to be registered.
> 2. Operate with the groups. It means that the user is a member of the
> remote group and we propose the groups to be assigned to the projects
> instead of the users.
> There is no concept of shadow groups yet, so it still has to be
> Same problem - in order to be able to assign the group to the project
> currently it has to exist in Keystone database.
> It should be either allowed to pre-create the project for a group
> (based on some specific flags in mappings), or it should be allowed to
> assign non-existing groups into the projects.
> I'd personally prefer to allow some special attribute to be specified
> in either the config or mapping which will allow project auto-creation.
> For example, user is added to the group "openstack" in the backend. In
> this case this group is the part of SAML assertions (in case when
> SAML2 is used as the protocol), and Keystone should recognize this
> group through the mapping. When user makes login attempt, Keystone
> should pre-create the project and assign pre-defined role in it. User
> gets access right away.
> Andrey Grebennikov
> Deployment Engineer
> Mirantis Inc, Mountain View, CA
> Kind Regards,
> Alexander Makarov,
> Senior Software Developer,
> Mirantis, Inc.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev