Open Stack

On 05/24/2016 10:30 PM, Adam Young wrote:
> 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.
>
>
>
Spec is here

https://review.openstack.org/#/c/313604/

>
>
>>
>> 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
>
>
>
> __________________________________________________________________________
> 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/06bb9855/attachment.html>