Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

[Adam Young]

On 02/02/2016 10:47 PM, Morgan Fainberg wrote:



On Feb 2, 2016 19:38, "Yee, Guang" <guang@hpe.com 
<mailto:guang@hpe.com>> wrote:

>
> 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?

>

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.




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.



E.g. local group would be role x, Y, z on domain q.

Domain specific role would be "role a, which is role x, y, z", and 
works like any other role for user/project(ordomain) combination.


The local groups we have all the code to do today.

--M
>
>
>
>
> Guang
>
>
>
>
>
> From: Henry Nash [mailto:henryna...@mac.com 
<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

Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

[Yee, Guang]

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

Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

[Morgan Fainberg]

On Feb 2, 2016 19:38, "Yee, Guang" <guang@hpe.com> wrote:
>
> 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?
>

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.

E.g. local group would be role x, Y, z on domain q.

Domain specific role would be "role a, which is role x, y, z", and works
like any other role for user/project(ordomain) combination.

The local groups we have all the code to do today.

--M
>
>
>
>
> 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
>
__
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

Re: [openstack-dev] [keystone] Domain Specific Roles vs Local Groups

[Adam Young]

On 02/02/2016 10:37 PM, Yee, Guang wrote:


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.




Let me see if I can say the same thing clearer:

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.



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.



You can't do it with groups alone.

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe

[openstack-dev] [keystone] Domain Specific Roles vs Local Groups

[Henry Nash]

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