[openstack-dev] [keystone] Extending policy checking to include target entities
d.w.chadwick at kent.ac.uk
Tue Jul 23 19:56:54 UTC 2013
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.
> 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
The policy enforcement mechanism is
> flexible enough that extending it to other attributes should be fairly
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev