Open Stack

On 05/24/2016 01:55 PM, Alexander Makarov wrote:
> Colleagues,
>
> 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 
> away.

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:

Kerberos example
{
Realm: YOUNGLOGIC.NET
Principal: ayoung at YOUNGLOGIC.NET
REMOTE_GROUPS: ipausers,demo,bookworms
}


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 
> implemented.
>
> 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
> 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/20160524/134eeee7/attachment.html>