Open Stack

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
>