Open Stack

On 01/23/2013 04:17 PM, David Chadwick wrote:
>
>
> On 23/01/2013 20:32, Adam Young wrote:
>> I've been using the term role_assignments.  A role_assignement is an
>> attribute that resolves down to the link between a user an an
>> organization.
>
> this is not my understanding of a role assignment
>
>  There are role_assignemtns between groups and projects,
Yes, but...those are not used fro policy enforcement.  In order for that 
to be evaluated, a user must be assigned to the group.  Then the user 
gets the role assignement to that project, and that is what will show up 
in their token.


>
> clearly one can assign roles to anything. But this hardly helps when 
> ultimately we want to assign roles to users, since permissions are 
> also assigned to roles.
>
>> but what we care about at policy time is how those role assignments
>> resolve for the user in question.
>
> Correct. But actually the model should be more flexible than this. It 
> should be
>
> sets of X, Y, Z... are assigned permissions by a CSP
> users are assigned attributes X, Y, Z... by Keystone
>
> then you have an ABAC model. When X,Y,Z collapse to "role" only, then 
> you have a pure RBAC model

I haven't read that thoroughly through the policy engine code, but it is 
my understanding that, while RBAC is the primary implementation, it 
supports a wider array of rules.  It should be able to make decisions 
based on anything in the signed token, or possibly even the context of 
the web request.

This is beyond the scope of Keystone.  If we want full-blown ABAC policy 
we should be able to do it.  There still needs to be an agreement on 
"These of the set of attributes policy will accept" and "these are the 
set of attributes keystone will put in the token."
>
> Currently keystone has neither of the above models according to my 
> understanding

>
> regards
>
> David