On 07/23/2013 03:56 PM, David Chadwick wrote:
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.
An interesting model: attribute sets based on the service
for nova provide: project role assignments
for swift provide : user name
and so forth.
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."
THat is true. We just put a very limited set of attributes in the token
at present
Thus the plugin should be capable of adding any attribute to the
request to the policy engine.
Yes it can, and I think we need a way to manage the set of attributes
that are bound in a token.
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.
No, this is what is required today. If there were additional
attributes, they could be used.
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
I think we can do that with the current implementation. I am not
certain if the policy engine as it is currently implemented has access
to the entire HTTP request, but expanding it to have access should not
be difficult.
The biggest drawback is the fact that the rules are on "method name" and
thus you might have two "create" methods that conflict.
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
