Open Stack

Hi

Thanks for the various comments.  To clarify our goals here, they are to extend our current model to include (stealing from David's list):

i) A domain defined role which can be inherited by all projects in the domain as and when they are created (and this is separate from a role that is assigned only to the domain)
ii) To define the API extensions for i), in such a way that we could logically extend this to support in the future (subsequent to agreement) for
- A global role definition which can be inherited by all domains as and when they are created.
- A global role definition inherited by all projects in all domains

I'd make a couple of additional comments:
a) The (re)introduction of global roles is something we would have to think long and hard about.  At minimum, this is a design summit discussion with a lot of prep, so I don't believe this can be in scope for Havana (although agree, as above, with the idea of ensure any API extensions we do could be extended to support this in the future, as we agreed on the Keystone IRC call this week)
b) I also think the idea of defining inheritance criteria as part of the role definition (as opposed to the assignment) would be a big break from the past, and is something that we would need much more discussion on.  Again, a summit session if this really is thought to be appropriate.
c) The concept of "users of the project" is really a depreciated concept as distinct from simply those users that have been assigned roles on a project.  We only really maintain this as a hang over from previous identity versions, with the inclusion of the "default_project" concept as part of a user definition.
d) I also agree that doing partial inheritance is somewhat fraught with problems - and fore now, I think remains out of scope.


I appreciate that there are many different views and ideas, but we need to make some progress within some of the confines of our current conceptual architecture, provided we are not locking ourselves out of possible future extensions.  Hence, my proposal is as follows:

1) Extend the APIs to support i) and ii) above, with:

PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited 
...with the same for GET, HEAD and DELETE as per the current spec

I plan to reduce the current blueprint to just include this change.  If in the future we wanted to extend this to support more global roles we could do (but not part of this change):

PUT  /domains/users/{user_id}/roles/{role_id}
...for assigning a role to all domains, and...
PUT  /domains/users/{user_id}/roles/{role_id}/inherited
...for assigning an an inherited roles to all domains

As an aside, I personally find the order or terms in the role assignment apis to be odd....I'd much rather see something that mimics how we think about it, i.e.

Create an assignment for "role X for User Y on Project Z"

e.g. PUT /roles/{role_id}/users/{user_id}/projects/{project_id}

This would also fit nicer with these new apis, e.g. I think the following feels better:

PUT /roles/{role_id}/users/{user_id}/domains/{domain_id}/inherited

as would

PUT /roles/{role_id}/users/{user_id}/domains/inherited

...if we ever supported more global-ness.

I will raise a separate blueprint to propose that we support this new ordering (and depreciate the older style, although of course still support it for a few releases).  If people hate it, then we can kill that part of it!

2) Allowing the listing role assignments that affect a user

I will create a separate blueprint for the re-specification of "Get roles for a user" along the lines of making it clear that is "Get role assignments for user" and includes the effective roles a user has, whether directly assigned, by virtue of group membership or inherited from a domain.  This will be instead of the "effective" query string that was part of the current blueprint.  I think we probably do need some indication in the response list as to where the role assignment came from, since in complex cloud environments this avoids an admin having to hunt via various different api calls to determine the answer.

3) Policy extensions to better support division of administration 

There is already a blueprint that looks to solve one issue we have here - that of ensuring we can define policy by domain_id for UDPATE & DELETE of user, group and project objects, when you need to check the target of the api, not just the parameters (See:  https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target )

There is a further issue that this doesn't yet cover (as raised by Arvind), that we need a way of protecting role assignments.  For example, if  cloud admin puts an inherited role on a domain, they don't want the domain administrator to be able to remove it. We can solve this by ensure that the policy extension support we add can include role assignments - for instance, you could define a policy that required you to be in the same domain as the actor (i.e. user or group) in the role assignment you are creating/deleting.  This would prevent domain admins from changing role assignments that were applied by a cloud admin (to either domain or project)  I will amend  the blueprint to include this.

Henry

> 1. A global role definition which can be inherited by all domains as and when they are created.
> 2. A domain defined role which can be inherited by all projects in the domain as and when they are created.
> 3. A project defined role which can be inherited by all users of the project (this is the traditional inheritance in the hierarchical RBAC model, but I dont think Keystone supports hierarchical RBAC does it?).
> 4. A global role definition inherited by a domain that can be inherited by all projects in the domain
> 5. A global role definition inherited by a domain and by a project in the domain that can be inherited by users of the project
> 6. A domain defined role inherited by a project in the domain that can be inherited by users of the project


On 7 Jun 2013, at 09:17, David Chadwick wrote:

> Hi Arvind
> 
> On 06/06/2013 23:02, Tiwari, Arvind wrote:
>> Hi Henry,
>> 
>> I am totally agree with David Chadwick that roleDefs itself should have
>> enough info so that underline system (role assignment) can make some
>> decision whether roleDef is inheritable or not. Below is my proposal
>> which is extensible and pretty much aligned with David’s thoughts.
>> 
> 
> Before diving into the implementation details, perhaps we should agree which types of inheritance should be supported. Lets try to list all of the inheritance possibilities, and then decide which should be supported (or not).
> 
> 1. A global role definition which can be inherited by all domains as and when they are created.
> 2. A domain defined role which can be inherited by all projects in the domain as and when they are created.
> 3. A project defined role which can be inherited by all users of the project (this is the traditional inheritance in the hierarchical RBAC model, but I dont think Keystone supports hierarchical RBAC does it?).
> 4. A global role definition inherited by a domain that can be inherited by all projects in the domain
> 5. A global role definition inherited by a domain and by a project in the domain that can be inherited by users of the project
> 6. A domain defined role inherited by a project in the domain that can be inherited by users of the project
> 
> Next we have to decide if an inheritable role can be partially inherited or not. By partial inheritance, I mean that only a subset of the subordinates can inherit the role definition, as opposed to the complete set of all subordinates e.g. if a global role is specified to be inheritable, does this mean that all domains will automatically inherit it, or should there be a mechanism to specify which domains can inherit it. This can get messy, because now you need to decide whether partial inheritance is based on a white list or a black list, meaning either only those subordinates that are listed can inherit the definition, or all subordinates which are not listed can inherit the definition.
> 
> My preference would be to only support full inheritance in the first instance, unless someone has a good argument to make for partial inheritance
> 
> regards
> 
> David
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130607/73bb5e9f/attachment.html>