Open Stack

On Wed, May 25, 2016 at 2:57 AM Jamie Lennox <jamielennox at gmail.com> wrote:

> On 25 May 2016 at 03:55, Alexander Makarov <amakarov at mirantis.com> 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>
>> 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.
>>
>
> This is something that has come up a few times as a workflow problem. For
> some group of users you should end up with your own project that doesn't
> exist until the first time you log in. This is something i think we could
> extend the mapper to handle. It wouldn't be user authenticated immediately,
> just solve the workflow of personal projects.
>

I completely agree with the solution that Jamie is describing here
(although I think it has even more potential than just personal projects),
and attempted to capture it in this keystone spec:

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


>
>
>> 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.
>>
>
> I would prefer not to do this. It either involves creating a user and then
> somehow associating what federated information they will present with
> later, or allowing you to create a user with a predetermined or predictable
> id. I dont think we should add either of those APIs.
>
>
>>
>> 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.
>>
>
> I'm not sure what you want for shadow groups here. Groups are always a
> keystone concept, they have never been ephemeral in the way that federated
> users used to be. Are you wanting  to make it so that keystone groups are
> auto created?
>
> Mapping federated users into groups has always been the way federation was
> designed in keystone because even though you can't know the actual users
> that are going to log in, it is very likely they fall into something that
> can fairly easily be categorized by looking at the roles that come in from
> the IDP assertion. So your mapping does something like "if user has the
> admin role put them in the federated-admin group", the federated-admin
> group has already been established and already has roles on a number of
> projects. Users are then automatically granted those roles on those
> projects. You could go so far as to check for user names in the mapping
> here but that's not a sustainable solution.
>
>
>> It should be either allowed to pre-create the project for a group (based
>> on some specific flags in mappings),
>>
>
> maybe - if you created the groups why don't you know the projects they are
> going to be in?
>
>
>> or it should be allowed to assign non-existing groups into the projects.
>>
>
> still not sure on this non-existing groups concept.
>
>
>>
>> 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.
>>
>>
> So yea, i'm interested in why the current federation mapping users to
> groups isn't what you're asking for? I can see the auto create project for
> user case, but i'm struggling to see why you would want to auto create
> projects for groups of users you didn't set up.
>
>
>>
>> --
>> 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
>
-- 
-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160601/be33cb24/attachment.html>