<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 02/02/2016 10:37 PM, Yee, Guang
wrote:<br>
</div>
<blockquote
cite="mid:C73B35E94B12854596094F2CA8668549643DB214@G4W3292.americas.hpqcorp.net"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
presume there’s a spec coming for this “seductive approach”?
Not sure if I get all of it. From what’s been described
here, conceptually, isn’t “local groups”, DSRs, or role
groups the same thing?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Guang<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Henry Nash [<a class="moz-txt-link-freetext" href="mailto:henrynash9@mac.com">mailto:henrynash9@mac.com</a>]
<br>
<b>Sent:</b> Monday, February 01, 2016 3:50 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for
usage questions)<br>
<b>Subject:</b> [openstack-dev] [keystone] Domain
Specific Roles vs Local Groups<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">During the recent keystone midcycle, it
was suggested than an alternative domain specific roles (see
spec:
<a moz-do-not-send="true"
href="https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst">https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst</a> and
code patches starting at:
<a moz-do-not-send="true"
href="https://review.openstack.org/#/c/261846/">https://review.openstack.org/#/c/261846/</a>)
might be to somehow re-use the group concept. This was
actually something we had discussed in previous proposals
for this functionality. As I mentioned during the last day,
while this is a seductive approach, it doesn’t actually
scale well (or in fact provide the right abstraction). The
best way to illustrate this is with an example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Let’s say a customer is being hosted by a
cloud provider. The customer has their own domain containing
their own users and groups, to keep them segregated from
other customers. The cloud provider, wanting to attract as
many different types of customer as possible, has created a
set of fine-grained global roles tied to APIs via the policy
files. The domain admin of the customer wants to create a
collection of 10 such fine-grained roles that represent some
function that is meaningful to their setup (perhaps it’s job
that allows you to monitor resources and fix a subset of
problems).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With domain specific roles (DSR) , the
domain admin creates a DSR (which is just a role with a
domain_id attribute), and then adds the 10 global policy
roles required using the implied roles API. They can then
assign this DSR to all the projects they need to, probably
as a group assignment (where the groups could be local,
federated or LDAP). One assignment per project is required,
so if there were, over time, 100 projects, then that’s 100
assignments. Further, if they want to add another global
role (maybe to allow access to a new API) to that DSR, then
it’s a single API call to do it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The proposal to use groups instead would
work something like this: We would support a concept of
“local groups” in keystone, that would be independent of
whatever groups the identity backend was mapped to. In order
to represent the DSR, a local group would be created
(perhaps with the name of the functional job members of the
group could carry out). User who could carry out this
function would be added to this group (presumably we might
also have to support “remote” groups being members of such
local groups, a concept we don’t really support today, but
not too much of a stretch). This group would then need to be
assigned to each project in turn, but for each of the 10
global roles that this “DSR equivalent” provided in turn (so
an immediate increase by a factor of N API calls, where N is
the number of roles per DSR) - so 1000 assignments in our
example. If the domain admin wanted to add a new role to (or
remove a role from) the “DSR”, they would have to do another
assignment to each project that this “DSR” was being used
(100 new assignments in our example). Again, I would
suggest, much less convenient.<o:p></o:p></p>
</div>
</div>
</blockquote>
<br>
Let me see if I can say the same thing clearer:<br>
<br>
Groups will only map to a single set of users to projects. If you
have two or more distince sets of users, and you want to map them to
two distinct sets of projects, groups won't help. You will end up
having to duplicate the structure of the role assignments for each
group.<br>
<br>
<br>
DSRs are essentially templates of role assignments. If you want to
make it so users of your cloud get only operations on VMs, read on
glance, and that is it, you create a domain specific role which
points only to those system defined roles, and you use that. <br>
<br>
<br>
You can't do it with groups alone.<br>
<br>
<blockquote
cite="mid:C73B35E94B12854596094F2CA8668549643DB214@G4W3292.americas.hpqcorp.net"
type="cite">
<div class="WordSection1">
<div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Given the above, I believe the current
DSR proposal does provide the right abstraction and
scalability, and we should continue to review and merge it
as planned. Obviously this is still dependant on Implied
Roles (either in its current form, or a modified version).
Alternative code of doing a one-level-only inference part of
DSRs does exist (from an earlier attempt), but I don’t think
we want to do that if we are going to have any kind of
implied roles.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Henry<o:p></o:p></p>
</div>
</div>
<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>