<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 May 2016 at 03:55, Alexander Makarov <span dir="ltr"><<a href="mailto:amakarov@mirantis.com" target="_blank">amakarov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><div>Colleagues,</div><div><br></div><div>here is an actual use case for shadow users assignments, let's discuss possible solutions: all suggestions are appreciated.</div><div><br></div></div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Andrey Grebennikov</b> <span dir="ltr"><<a href="mailto:agrebennikov@mirantis.com" target="_blank">agrebennikov@mirantis.com</a>></span><br>Date: Tue, May 24, 2016 at 9:43 AM<br>Subject: keystone federation user story<br>To: Alexander Makarov <<a href="mailto:amakarov@mirantis.com" target="_blank">amakarov@mirantis.com</a>><br><br><br><div dir="ltr">Main production usecase:<div>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.</div><div><br></div><div>Two different approaches.</div><div>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.</div><div>Nonetheless there was a bug <a href="https://bugs.launchpad.net/keystone/+bug/1313956" target="_blank">https://bugs.launchpad.net/keystone/+bug/1313956</a> 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.</div><div><br></div><div>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.</div><div><br></div><div>Disadvantages: less control and order (will potentially end up with infinite empty projects).</div><div>Benefits: user is authorized right away.</div></div></div></div></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>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.</div><div><br></div><div>Disadvantages: high risk of administrator's mistake when typing user's ID.</div><div>Benefits: user doesn't have to execute first dummy authentication in order to be registered.</div></div></div></div></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>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.</div><div>There is no concept of shadow groups yet, so it still has to be implemented.</div><div><br></div><div>Same problem - in order to be able to assign the group to the project currently it has to exist in Keystone database.</div></div></div></div></blockquote><div><br></div><div>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?<br><br></div><div>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. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>It should be either allowed to pre-create the project for a group (based on some specific flags in mappings),</div></div></div></div></blockquote><div><br></div><div>maybe - if you created the groups why don't you know the projects they are going to be in? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div> or it should be allowed to assign non-existing groups into the projects.</div></div></div></div></blockquote><div><br></div><div>still not sure on this non-existing groups concept. <br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>I'd personally prefer to allow some special attribute to be specified in either the config or mapping which will allow project auto-creation.</div><div>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.</div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><div><br clear="all"></div></font></span></font></span></div></div></div></blockquote><div><br></div><div>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. <br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><div><div><br></div>-- <br><div><div dir="ltr">Andrey Grebennikov<div>Deployment Engineer</div><div>Mirantis Inc, Mountain View, CA</div></div></div>
</div></font></span></font></span></div><span class="HOEnZb"><font color="#888888">
</font></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><font style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px" color="#000000">Kind Regards,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px" color="#000000">Alexander Makarov,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px" color="#000000">Senior Software Developer,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px" color="#000000">Mirantis, Inc.</font><br></div></div></div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>