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