<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:47 PM, Morgan Fainberg
wrote:<br>
</div>
<blockquote
cite="mid:CAGnj6atdtU6=Gp_FHwmybZngPSbUYcsWqF5RbO81EUHNY711HQ@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Feb 2, 2016 19:38, "Yee, Guang" <<a moz-do-not-send="true"
href="mailto:guang.yee@hpe.com">guang.yee@hpe.com</a>>
wrote:<br>
><br>
> 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?<br>
></p>
<p dir="ltr">Subtle differences. Local groups would be locked to a
specific scope / group of scopes. And Domain Specific Role (dont
use the initialism/acronym overloaded), would be global that
could be assinged to many various scopes. </p>
</blockquote>
<br>
So long as local groups are considered in addition to Domain
specific roles, and not as a replacement. We can do local groups
today, by allowing users from, say a Federated backend, to be
enrolled into a group defined in a separate domain.<br>
<br>
<blockquote
cite="mid:CAGnj6atdtU6=Gp_FHwmybZngPSbUYcsWqF5RbO81EUHNY711HQ@mail.gmail.com"
type="cite">
<p dir="ltr">E.g. local group would be role x, Y, z on domain q. </p>
<p dir="ltr">Domain specific role would be "role a, which is role
x, y, z", and works like any other role for
user/project(ordomain) combination. </p>
<p dir="ltr">The local groups we have all the code to do today. </p>
<p dir="ltr">--M<br>
> <br>
><br>
> <br>
><br>
> Guang<br>
><br>
> <br>
><br>
> <br>
><br>
> From: Henry Nash [mailto:<a moz-do-not-send="true"
href="mailto:henrynash9@mac.com">henrynash9@mac.com</a>] <br>
> Sent: Monday, February 01, 2016 3:50 PM<br>
> To: OpenStack Development Mailing List (not for usage
questions)<br>
> Subject: [openstack-dev] [keystone] Domain Specific Roles
vs Local Groups<br>
><br>
> <br>
><br>
> Hi<br>
><br>
> <br>
><br>
> 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"><a class="moz-txt-link-freetext" 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></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:<br>
><br>
> <br>
><br>
> 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).<br>
><br>
> <br>
><br>
> 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.<br>
><br>
> <br>
><br>
> 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.<br>
><br>
> <br>
><br>
> 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.<br>
><br>
> <br>
><br>
> Henry<br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage
questions)<br>
> Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>
<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>