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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
