Open Stack

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

userid
domainid
role_assignments: a collection of tuples  (project, role)

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.  If there are other 
attributes that people want consume for  policy enforcement, they can 
add them to custom token providers.  The policy enforcement mechanism is 
flexible enough that extending it to other attributes should be fairly 
straightforward.