Open Stack

On 12/18/2012 07:18 PM, Henry Nash wrote:
> So I personally don't think this is the right approach.  My rationale is:
>
> 1) We already have the standard "RBAC based" groups proposal & implementation that has been reviewed several times  - so there is no argument really here for minimising code development or wasted effort.  GIven the review comments so far, this will all be ready to be merged this week.
SQL only.  We still will need LDAP shortly thereafter.


> 2) I still think we do not have consensus of what parts of attribute mapping/control api would be exposed to administrators to achieve the equivalent of groups.  In my view,  most installations in the short to medium term want an RBAC solution (that's what they know and it is sufficient).  Complicating the administration with a general purpose AM/ABAC semantics would be a negative.  Longer term, for complex installations (and particular when we want federation), then the AM/ABAC model comes into its own and will be a real differentiator for OpenStack.
Agreed.


> 3) We should therefore complete the RBAC groups approach and make that our reference implementation.

RBAC is the enforcemnt.  we are talking about Role Assignment.

> 4) Once we have 3), we can then look at how we might start using AM/ABAC - e.g. using it to set/get role assignments.  We can decide as we close in on the Grizzly dates whether this support is experimental or production.

We are only talking about how Roles are assigned.

All that said, Iagree that finishing the Groups proposal as is should 
happen first.  We can always retrofit Groups to use Mapping based Role 
Assignment.  While it is slightly more work, it is much lower risk.  I 
think the mapping proposal has legs, but I want to make sure those legs 
are strong enough to hold up the whole structure first, and I don't want 
to rush them into production.


>
> Henry
>
>
>
>> Henry, Adam, Joe et al
>>
>> this is how I propose that attribute mapping is integrated into Keystone order to minimise code development and wasted effort
>>
>> 1. Henry produces code that stores groups and group memberships in Keystone
>>
>> 2. Henry produces code that retrieves user groups from keystone
>>
>> 3. Henry does not produce code that links groups to roles and that iterates through roles to find out who the group members are that have the roles. Instead
>>
>> 4. Kristy finishes off the super API, that given a set of input groups, returns the set of roles and tenants that the user is a member of. (This is already partly written, but is not part of the code that has already been submitted to git. But it will use the code that has been submitted)
>>
>> 5. Henry uses Kristy's code
>>
>> regards
>>
>> David
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev