Open Stack

David,

Ok, so as you know the keystone model today we do combine some of the things you describe, namely, we require you to specify the object(s) in question for which an actor is given a given a specific role - that is the keystone definition of role-assignment.  I appreciate that this is not the same as some other systems.  I don't think we are contemplating a change on this right now - although I think we all welcome the general discussion on whether a different definition makes sense in the future.

My statement on inheritance, was therefore made in the context of simple how you specify "objects" - and I favour support existing containers (namely domains and projects) with (top-down) inheritance for how you describe multiple objects, rather than supporting arbitrary expressions.  Actually, to be honest, I think the scope structure we defined could support either model - and we can arm wrestle over which or both going forward.

Henry
On 14 Jun 2013, at 14:06, David Chadwick wrote:

> Hi Henry and Guan
> 
> I think we still dont have the correct RBAC model, therefore implementation will always be more complex that it would be if the model was simple and clear.
> 
> Henry said " it's just that I believe inheritance IS the answer, but also agree we need a consistent api to apply it."
> 
> Inheritance cannot be the answer. All that inheritance does, in a well designed system, is reduce the number of role assignments (or role definitions) that are needed, since one assignment (or definition) with inheritance can apply to multiple subjects rather than one. You can always do everything in RBAC without inheritance that you can do with inheritance. So inheritance is not the answer. If you think it is, I suggest you are not asking the right question.
> 
> Guan (I think) said "Role assignment is really about assigning a given [role] to a given [user or group] for [a given project | a given domain | all projects within a given domain | all projects in all domains | all domains]."
> 
> I think this is mixing up user-role assignment and permission-role assignment (and is also mixing up groups with roles).
> 
> On the first point, user role assignment should be only about assigning a role to a user. This is a very simple and clean process. Permission assignment should be about giving the role a permission to act within a given project and/or domain. Again, a very clean and simple assignment.
> 
> So admin might give the role A to user U. Then the owner of a project (or domain) might give role A permission to perform a certain action on a certain resource of the project (or domain). There should be no need to constrain role assignment to a project or domain as Guan suggests, since if the role is not given any permissions in the project or domain, it does not confer any permissions on the user. So the role assignment has zero effect. Because you are conflating user role assignment and permission role assignment together, you are making the model far more complex than it needs to be.
> 
> On the second point, since a role defines a group of users (i.e. those that have been assigned the "group" role), there is no need to have groups or therefore no need to assign roles to groups, or groups to users, since a different "group" role can be used to determine the group membership. All you need to do is assign permissions to the "group" role, or perform role mapping from the "group" role to the other role which already has the required permissions. For example. Say users A and B are in group 1. Role 1 has permission X. You want to easily give permission X to users A and B. The simplest approach is to give permission X to the role "group 1", or to map group 1 to role 1. Assigning role 1 to group 1 only unnecessarily complicates the role assignment model (since you are effectively assigning roles to roles).
> 
> regards
> 
> David
> 
> On 14/06/2013 12:39, Henry Nash wrote:
>> Hi
>> 
>> So discussion has been raging on the etherpad () on this topic following the IRC discussion.  Due to the depth of discussion, this pad is now quite long.  I think we do have a couple of potential ways forward:
>> 
>> 1) The general consensus is that ideally we should move to a new api for role assignments, including treating a role assignment as first class entity (with a typical v3 style CRUD api).  Although there was still differing views on how "scope" should be defined, we settled on going forward with Option F (which is really the same as Option E, but with an "inheritance" model of scope, rather than an "expression" model).  The challenge with this is that this would be a fairly big change (really have to re-write all our grant tables underneath, provide the new api, and allow intermix with the old apis, fix all the corner cases we haven't thought of yet, etc.).  Given we are a month away from m2, a number of people have concerns as to whether we can achieve this in the time frame.
>> 
>> 2) A stepping stone approach is suggested in Option G, where, for Havana, we:
>> - Use the new api JUST for listing complete role assignments (a bit like the current proposal of https://review.openstack.org/#/c/32394/), but use the new role-assignment entity as the format to the data (less an role_assignment_id).  Links would point a the old assignment api format for how you would change the entities
>> - Extend the old assignment apis to just allow you to inherit roles to projects of a domain, buy adding the /inherited_to_projects term to the urls, e.g.:
>> PUT /domains/{domain_id}/users/{user_id}/roles/{role_id}/inherited_to_projects
>> ...and the same for GET, HEAD, DELETE.
>> - For the next release, we commit to move to provide full support for the new role-assignment entity and api, and depreciate (but still support) the old apis.  The only change to the format returned by GET /role-assignments would be the inclusion of a role_assignment_id and the links would now point to the new api.
>> 
>> Thoughts?
>> 
>> Henry
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>