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?


Guang


From: Henry Nash [mailto:henryna...@mac.com]
Sent: Monday, February 01, 2016 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

Hi

During the recent keystone midcycle, it was suggested than an alternative 
domain specific roles (see spec: 
https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/domain-specific-roles.rst
 and code patches starting at: https://review.openstack.org/#/c/261846/) 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:

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).

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.

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.

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.

Henry
__________________________________________________________________________
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

Reply via email to