Open Stack

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>
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov <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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160524/45356838/attachment.html>