<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/24/2016 10:30 PM, Adam Young
wrote:<br>
</div>
<blockquote cite="mid:57450E38.7040200@redhat.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 05/24/2016 01:55 PM, Alexander
Makarov wrote:<br>
</div>
<blockquote
cite="mid:CAKb2=11d-vUXFx0pKO2c8XmwrL8mr2tQH7L4dVSxnwEPeEQZOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">
<div class="gmail_default">Colleagues,</div>
<div class="gmail_default"><br>
</div>
<div class="gmail_default">here is an actual use case for
shadow users assignments, let's discuss possible
solutions: all suggestions are appreciated.</div>
<div class="gmail_default"><br>
</div>
</div>
<div class="gmail_quote">---------- Forwarded message
----------<br>
From: <b class="gmail_sendername">Andrey Grebennikov</b> <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:agrebennikov@mirantis.com">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 moz-do-not-send="true"
href="mailto:amakarov@mirantis.com">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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
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:<br>
<br>
Kerberos example<br>
{<br>
Realm: YOUNGLOGIC.NET<br>
Principal: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:ayoung@YOUNGLOGIC.NET">ayoung@YOUNGLOGIC.NET</a><br>
REMOTE_GROUPS: ipausers,demo,bookworms<br>
}<br>
<br>
<br>
Another API will allow for query if a user exists.<br>
<br>
<br>
<br>
</blockquote>
Spec is here<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/313604/">https://review.openstack.org/#/c/313604/</a><br>
<br>
<blockquote cite="mid:57450E38.7040200@redhat.com" type="cite"> <br>
<br>
<blockquote
cite="mid:CAKb2=11d-vUXFx0pKO2c8XmwrL8mr2tQH7L4dVSxnwEPeEQZOQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<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><br>
</div>
<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><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><br>
</div>
<div>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.</div>
<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=""><font color="#888888">
<div><br clear="all">
<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></div>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>