Open Stack

On 07/23/2013 03:56 PM, David Chadwick wrote:
>
>
> On 23/07/2013 18:36, Adam Young wrote:
>> On 07/23/2013 01:17 PM, David Chadwick wrote:
>>> Of course the tricky thing is knowing which object attributes to fetch
>>> for which user API requests. In the general case you cannot assume
>>> that Keystone knows the format or structure of the policy rules, or
>>> which attributes each will need, so you would need a specific tailored
>>> context handler to go with a specific policy engine. This implies that
>>> the context handler and policy engine should be pluggable Keystone
>>> components that it calls, and that can be switchable as people decide
>>> use different policy engines.
>> We are using a model where Keystone plays the mediator, and decides what
>> attributes to include.  The only attributes we currently claim to
>> support are
>
> what I am saying is that, in the long term, this model is too 
> restrictive. It would be much better for Keystone to call a plugin 
> module that determines which attributes are needed to match the policy 
> engine that is implemented.

An interesting model:  attribute sets based on the service

for nova provide:  project role assignments
for swift provide : user name

and so forth.


>
>>
>> userid
>> domainid
>> role_assignments: a collection of tuples  (project, role)
>
> I thought in your blog post you said "While OpenStack calls this Role 
> Based Access Control (RBAC) there is nothing in the mechanism that 
> specifies that only roles can be used for these decisions. Any 
> attribute in the token response could reasonably be used to 
> provide/deny access. Thus, we speak of the token as containing 
> authorization attributes."

THat is true.  We just put a very limited set of attributes in the token 
at present

>
> Thus the plugin should be capable of adding any attribute to the 
> request to the policy engine.
Yes it can, and I think we need a way to manage the set of attributes 
that are bound in a token.

>
>
>>
>> Objects in openstack are either owned by users (in Swift) or by Projects
>> (Nova and elsewhere).  Thus, providing userid and role_assignments
>> should be sufficient to make access decisions.
>
> this is too narrow a viewpoint and contradicts your blog posting.
No, this is what is required today.  If there were additional 
attributes, they could be used.

>
>  If there are other
>> attributes that people want consume for policy enforcement, they can
>> add them to custom token providers.
>
> the token is not the only place that attributes can come from. The 
> token contains subject attributes, but there are also resource 
> attributes and environmental attributes that may be needed by the 
> policy engine. Thus I am suggesting that we should design for 
> eventuality. I think that re-engineering the existing code base should 
> allow the context handler to be pluggable, whilst the first 
> implementation will simply use the attributes that are currently being 
> used, so that you have backwards compatibility
I think we can do that with the current implementation.  I am not 
certain if the policy engine as it is currently implemented has access 
to the entire HTTP request, but expanding it to have access should not 
be difficult.

The biggest drawback is the fact that the rules are on "method name" and 
thus you might have two "create" methods that conflict.

>
> regards
>
> David
>
>
>  The policy enforcement mechanism is
>> flexible enough that extending it to other attributes should be fairly
>> straightforward.
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev