Open Stack

On 06/19/2013 01:14 PM, David Chadwick wrote:
> Hi Adam
>
> as I said in a previous post (to which Henry replied "but 
> unfortunately that is not the way Keystone currently works" my 
> paraphrase), we should not even be assigning roles to users to 
> projects, as this is mixing up user-role assignments and 
> permission-role assignments. We/keystone should simply be assigning 
> roles to users. The service will then assign the permissions to the 
> roles that it wants to, and I am sure that most of the complexity you 
> are now trying to grapple with will go away, because there will be no 
> limitations on where the roles can be used. Its up to the service to 
> decide if a role has permissions or not.

So, a project is a scope of a role, as is a domain.  Unless the role 
becomes a de factor tuple of "role_project"  I don't see how we can 
acheive a scalable RBAC system anyway.  President is a role, but you 
have to be President of the United States in order to get on Air Force One.

Another way to put it is that we are just assigning a set of roles to a 
user.  We just decide which set of roles to assign a-priori before they 
get to the service, by having them state which project they plan on 
using the token for, and the appropriate set of roles is assigned.

If we were to go with the full blown Attribute Based Access control, we 
would still be faced with the same problem.  The end-to-end problem is 
:from the attributes that the user has what set of actions can the user 
perform.  The Keystone abstraction is to make a middle layer:  roles 
within projects.  We've scoped keystone responsibilities down to 
figuring out how to assign these.

I am currently splitting the assignments backend from identity, and that 
is going to be essential to any forward movement toward a reasonable 
Keystone architecture. Let me post it as a work in progress so you can 
see where I am headed, and we can discuss.  I'd rather not have to deal 
with rebasing a bunch of changes for a one-off solution to the overall 
problem when we are much closer to a general solution than we realize.


>
> I appreciate that this is not the way that Keystone currently works, 
> and you may not have time to change it for Havana, but rather than 
> trying to add more complexity to solve its current skewed model, why 
> not try to advance down an alternative path that veers towards the 
> classical clean RBAC model and simplification of the role assignment 
> problem? And target on Ice for the introduction of the revised model
>
> regards
>
> David
>
> On 19/06/2013 15:36, Adam Young wrote:
>> So I'd like to redefine the problem definition here:
>>
>> "Provide a mechanism by which role assignments can be specified for more
>> than one project."