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* <[email protected]
<mailto:[email protected]>>
Date: Tue, May 24, 2016 at 9:43 AM
Subject: keystone federation user story
To: Alexander Makarov <[email protected]
<mailto:[email protected]>>
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: [email protected]
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:[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
