Open Stack

Hi Tiwari

On 11/06/2013 21:18, Tiwari, Arvind wrote:
> Think about growing number of service and above mentioned requirement,
> we will end up with so many  roleDefs which will have duplicate
> capability and hence redundant info to maintain in policy. At the same
> time this solution does not address separation of concerns, we are
> unnecessary overloading the roleDefs to impose role inheritance behavior
> which is not its concern. The above mentioned requirement can be easily
> achievable by single roleDef (may be XYZ-role-Svc1) if we remove
> *inheritedTo * concern from roleDef and place it some ware else, role
> assignment is the right place to address this concern, how that we need
> to figure out.

There are many different components in RBAC, viz:

i) the specification of a role - its syntax, values etc
ii) the role assignment rules - who the role can be assigned to
iii) the permission assignment rules - which permissions can be assigned 
to the role
iv) the delegation rules - whether the role is delegatable or not, by 
whom, and to what depth,

to name just some of them. You may have others.

Modelling RBAC in Keystone will eventually need most (if not all plus 
more) of the above to be held somewhere. The roleDefs table seems a 
sensible place to hold the above, but of course, the information could 
be distributed into multiple tables.

Any assignment of a role to a user must conform to ii) above.
Any assignment of a privilege to a role must conform to iii) above.
Any delegation of roles must conform to iv) above,
etc.

Unless I have misunderstood you, you seem to want to specify the rules 
for role inheritance into the actual assignment of a role to a subject. 
In my opinion this is the wrong place to specify the role assignment 
rules, but it would be the right place to specify a dynamic assignment 
restriction which is in conformity to the rules (if we want to allow 
dynamic restrictions).

regards

David