Open Stack

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.

>
> 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."

Thus the plugin should be capable of adding any attribute to the request 
to the policy engine.


>
> 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.

  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

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