Re: [openstack-dev] [Keystone] Splitting up the assignment component

2014-11-26 Thread David Chadwick
I tend to agree with Morgan. There are resources and there are users.
And there is something in the middle that says which users can access
which resources. It might be an ACL, a RBAC role, or a set of ABAC
attributes, or something else (such as a MAC policy). So to my mind this
middle bit, whilst being connected to both resources and users, is
separate from both of them. So we should not artificially put it with
just one of them.

FYI, the roles in RBAC are part of the policy specification. You define
the roles, their hierarchical relationships, then assign both users and
resources (privileges actually) to them. So roles could be part of the
policy specification, except that the policy is distributed, so in which
part of the distributed policy would you put it? Would it be in the
specification of roles to actions, or in the attribute mappings, or in
the user to attribute assignments?

regards

David

On 25/11/2014 16:42, Morgan Fainberg wrote:
 
 On Nov 25, 2014, at 4:25 AM, Henry Nash hen...@linux.vnet.ibm.com wrote:

 Hi

 As most of you know, we have approved a spec 
 (https://review.openstack.org/#/c/129397/) to split the assignments 
 component up into two pieces, and the code (divided up into a series of 
 patches) is currently in review (https://review.openstack.org/#/c/130954/). 
 While most aspects of the split appear to have agreement, there is one 
 aspect that has been questioned - and that is the whether roles' should be 
 in the resource component, as proposed?

 First, let's recap the goals here:

 1) The current assignment component is really what's left after we split 
 off users/groups into identity some releases ago.  Assignments is pretty 
 complicated and messy - and we need a better structure (as an example, just 
 doing the split allowed me to find 5 bugs in our current implementation - 
 and I wouldn't be surprised if there are more).  This is made more urgent by 
 the fact that we are about to land some big new changes in this area, e.g. 
 hierarchical projects and a re-implemntation (for performance) of 
 list_role_assignments.

 2) While Keystone may have started off as a service where we store all the 
 users, credentials  permissions needed to access other OpenStack services, 
 we more and more see Keystone as a wrapper for existing corporate 
 authentication and authorisation mechanisms - and it's job is really to 
 provided a common mechanism and language for these to be consumed across 
 OpenStack services.  To do this well, we must make sure that the keystone 
 components are split along sensible lines...so that they can individually 
 wrap these corporate directories/services.  The classic case of this was are 
 previous split off of Identity...and this new proposal takes this a step 
 further.

 3) As more and more broad OpenStack powered clouds are created, we must 
 makes sure that our Keystone implementation is as flexible as possible. We 
 already plan to support new abstractions for things like cloud providers 
 enabling resellers to do business within one OpenStack cloud (by providing 
 hierarchical multi-tenancy, domain-roles etc.). Our current assignments 
 model is a) slightly unusual in that all roles are global and every 
 assignment has actor-target-role, and b) cannot easily be substituted for 
 alternate assignment models (even for the whole of an OpenStack 
 installation, let alone on a domain by domain basis)

 The proposal for splitting the assignment component is trying to provide a 
 better basis for the above.  It separates the storing and CRUD operations of 
 domain/projects/roles into a resource component, while leaving the pure 
 assignment model in assignment.  The rationale for this is that the 
 resource component defines the entities that the rest of the OpenStack 
 services (and their policy engines) understand...while assignment is a pure 
 mapper between these entities. The details of these mappings are never 
 exposed outside of Keystone, except for the generation of contents of a 
 token.  This would allow new assignment models to be introduced that, as 
 long as they support the api to list what role_ids are mapped to project_id 
 X for user_id Y, then the rest of OpenStack would never know anything had 
 changed.

 So to (finally) get the the point of this post...where should the role 
 definitions live? The proposal is that these live in resource, because:

 a) They represent the definition of how Keystone and the other services 
 define permission - and this should be independent of whatever assignment 
 model we choose
 b) We may well chose (in the future) to morph what we currently means as a 
 role...into what they really are, which is a capability.  Once we have 
 domain-specifc roles (groups), which map to global roles, then we may well 
 end up, more often than not, with a role representing a single API 
 capability.  Roles might even be created simply by a service registering 
 its capabilities with Keystone.  Again, this 

Re: [openstack-dev] [Keystone] Splitting up the assignment component

2014-11-26 Thread Adam Young

On 11/26/2014 09:52 AM, David Chadwick wrote:

I tend to agree with Morgan. There are resources and there are users.
And there is something in the middle that says which users can access
which resources. It might be an ACL, a RBAC role, or a set of ABAC
attributes, or something else (such as a MAC policy). So to my mind this
middle bit, whilst being connected to both resources and users, is
separate from both of them. So we should not artificially put it with
just one of them.

FYI, the roles in RBAC are part of the policy specification. You define
the roles, their hierarchical relationships, then assign both users and
resources (privileges actually) to them. So roles could be part of the
policy specification, except that the policy is distributed, so in which
part of the distributed policy would you put it? Would it be in the
specification of roles to actions, or in the attribute mappings, or in
the user to attribute assignments?
I'd say that for this split we leave roles in assignment, but that when 
we get to the store policy rules in a database spec we move them to 
policy.


https://review.openstack.org/#/c/133814

as using Hierarchical rules to generate policy implies that the whole 
thing is in a unified, choherent structure.


https://review.openstack.org/#/c/125704/7




regards

David

On 25/11/2014 16:42, Morgan Fainberg wrote:

On Nov 25, 2014, at 4:25 AM, Henry Nash hen...@linux.vnet.ibm.com wrote:

Hi

As most of you know, we have approved a spec (https://review.openstack.org/#/c/129397/) to 
split the assignments component up into two pieces, and the code (divided up into a series of 
patches) is currently in review (https://review.openstack.org/#/c/130954/). While most aspects 
of the split appear to have agreement, there is one aspect that has been questioned - and that 
is the whether roles' should be in the resource component, as proposed?

First, let's recap the goals here:

1) The current assignment component is really what's left after we split off users/groups into 
identity some releases ago.  Assignments is pretty complicated and messy - and we 
need a better structure (as an example, just doing the split allowed me to find 5 bugs in our current 
implementation - and I wouldn't be surprised if there are more).  This is made more urgent by the fact that 
we are about to land some big new changes in this area, e.g. hierarchical projects and a re-implemntation 
(for performance) of list_role_assignments.

2) While Keystone may have started off as a service where we store all the users, 
credentials  permissions needed to access other OpenStack services, we more and 
more see Keystone as a wrapper for existing corporate authentication and authorisation 
mechanisms - and it's job is really to provided a common mechanism and language for these to 
be consumed across OpenStack services.  To do this well, we must make sure that the keystone 
components are split along sensible lines...so that they can individually wrap these 
corporate directories/services.  The classic case of this was are previous split off of 
Identity...and this new proposal takes this a step further.

3) As more and more broad OpenStack powered clouds are created, we must makes 
sure that our Keystone implementation is as flexible as possible. We already 
plan to support new abstractions for things like cloud providers enabling 
resellers to do business within one OpenStack cloud (by providing hierarchical 
multi-tenancy, domain-roles etc.). Our current assignments model is a) slightly 
unusual in that all roles are global and every assignment has 
actor-target-role, and b) cannot easily be substituted for alternate assignment 
models (even for the whole of an OpenStack installation, let alone on a domain 
by domain basis)

The proposal for splitting the assignment component is trying to provide a better basis for the above.  It 
separates the storing and CRUD operations of domain/projects/roles into a resource component, 
while leaving the pure assignment model in assignment.  The rationale for this is that the 
resource component defines the entities that the rest of the OpenStack services (and their policy engines) 
understand...while assignment is a pure mapper between these entities. The details of these mappings are 
never exposed outside of Keystone, except for the generation of contents of a token.  This would allow new 
assignment models to be introduced that, as long as they support the api to list what role_ids are 
mapped to project_id X for user_id Y, then the rest of OpenStack would never know anything had changed.

So to (finally) get the the point of this post...where should the role definitions live? 
The proposal is that these live in resource, because:

a) They represent the definition of how Keystone and the other services define 
permission - and this should be independent of whatever assignment model we 
choose
b) We may well chose (in the future) to morph what we currently means as a 

Re: [openstack-dev] [Keystone] Splitting up the assignment component

2014-11-25 Thread Morgan Fainberg

 On Nov 25, 2014, at 4:25 AM, Henry Nash hen...@linux.vnet.ibm.com wrote:
 
 Hi
 
 As most of you know, we have approved a spec 
 (https://review.openstack.org/#/c/129397/) to split the assignments component 
 up into two pieces, and the code (divided up into a series of patches) is 
 currently in review (https://review.openstack.org/#/c/130954/). While most 
 aspects of the split appear to have agreement, there is one aspect that has 
 been questioned - and that is the whether roles' should be in the resource 
 component, as proposed?
 
 First, let's recap the goals here:
 
 1) The current assignment component is really what's left after we split 
 off users/groups into identity some releases ago.  Assignments is pretty 
 complicated and messy - and we need a better structure (as an example, just 
 doing the split allowed me to find 5 bugs in our current implementation - and 
 I wouldn't be surprised if there are more).  This is made more urgent by the 
 fact that we are about to land some big new changes in this area, e.g. 
 hierarchical projects and a re-implemntation (for performance) of 
 list_role_assignments.
 
 2) While Keystone may have started off as a service where we store all the 
 users, credentials  permissions needed to access other OpenStack services, 
 we more and more see Keystone as a wrapper for existing corporate 
 authentication and authorisation mechanisms - and it's job is really to 
 provided a common mechanism and language for these to be consumed across 
 OpenStack services.  To do this well, we must make sure that the keystone 
 components are split along sensible lines...so that they can individually 
 wrap these corporate directories/services.  The classic case of this was are 
 previous split off of Identity...and this new proposal takes this a step 
 further.
 
 3) As more and more broad OpenStack powered clouds are created, we must makes 
 sure that our Keystone implementation is as flexible as possible. We already 
 plan to support new abstractions for things like cloud providers enabling 
 resellers to do business within one OpenStack cloud (by providing 
 hierarchical multi-tenancy, domain-roles etc.). Our current assignments model 
 is a) slightly unusual in that all roles are global and every assignment has 
 actor-target-role, and b) cannot easily be substituted for alternate 
 assignment models (even for the whole of an OpenStack installation, let alone 
 on a domain by domain basis)
 
 The proposal for splitting the assignment component is trying to provide a 
 better basis for the above.  It separates the storing and CRUD operations of 
 domain/projects/roles into a resource component, while leaving the pure 
 assignment model in assignment.  The rationale for this is that the 
 resource component defines the entities that the rest of the OpenStack 
 services (and their policy engines) understand...while assignment is a pure 
 mapper between these entities. The details of these mappings are never 
 exposed outside of Keystone, except for the generation of contents of a 
 token.  This would allow new assignment models to be introduced that, as long 
 as they support the api to list what role_ids are mapped to project_id X for 
 user_id Y, then the rest of OpenStack would never know anything had changed.
 
 So to (finally) get the the point of this post...where should the role 
 definitions live? The proposal is that these live in resource, because:
 
 a) They represent the definition of how Keystone and the other services 
 define permission - and this should be independent of whatever assignment 
 model we choose
 b) We may well chose (in the future) to morph what we currently means as a 
 role...into what they really are, which is a capability.  Once we have 
 domain-specifc roles (groups), which map to global roles, then we may well 
 end up, more often than not, with a role representing a single API 
 capability.  Roles might even be created simply by a service registering 
 its capabilities with Keystone.  Again, this should be independent of any 
 assignment model.

I think there is some dissonance in storing the roles in resource. The 
assignment backend is what controls how the actor is connected with the scope. 
If you’re keeping the role within the resource backend you’re now needing to 
have yet another way of correlating the data from the resource side (2 
elements) to the identity (user/group) side. The assignment backend is 
connecting the role to the actor and scope (project/domain), it should in some 
way be responsible for knowing what the role definition is. In the case of a 
crazy ABAC system, a role would need to be a mapping of attributes on the actor 
object, that now needs *another* layer of connection (similar to what we have 
now) to the roles in resource. Logically the roles seem tightly coupled to the 
assignment backend, not a loosely 
coupled-and-theoretically-can-be-completly-ignored. 

 c) By placing roles in the resource component,