Open Stack

Hi Adam

I think in the context of RBAC, President is only a role if all 
resources recognise it as such and assign it permissions, which in 
general they do not, so its not a useful role - it would have no 
permissions. OTOH, President of the USA, President of Brazil and 
President of Chile are separate roles with separate permissions. In the 
context of OpenStack, admin of swift is a different role to admin of 
keystone and therefore they should be clearly defined roles (not the 
same one). What the current OpenStack system has done is try to short 
circuit this by saying there is a single admin role and this is attached 
to different projects and different resources, but it is the same role, 
only when it is attached to different things it has different 
permissions. The model would be much clearer in my opinion if each role 
was clearly identified as such, and then each role could be assigned to 
users as required and given it own unique set of permissions.

regards

David

On 19/06/2013 19:11, Adam Young wrote:
> 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."
>