On Wed, May 25, 2016 at 2:57 AM Jamie Lennox <jamielen...@gmail.com> wrote:
> On 25 May 2016 at 03:55, Alexander Makarov <amaka...@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 <agrebenni...@mirantis.com> >> Date: Tue, May 24, 2016 at 9:43 AM >> Subject: keystone federation user story >> To: Alexander Makarov <amaka...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev