Hi Henry
using the XACML processing model, the functionality that you are
describing, which you say is currently partly missing from Keystone, is
that of the context handler. Its job is to marshall all the attributes
that are needed and put them into the request context for calling the
policy engine. So it should be perfectly possible for the API call to
simply name a target object and an operation (such as Delete userID),
then the keystone context handler can fetch the various attributes of
the target (using a function called the Policy Information Point in
XACML), add them to the request to the policy engine (in the delete
userID case all you might need to fetch is the domain id), then get the
response from the policy engine, and if granted, hand back control to
Keystone to continue processing the request.
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.
Hope this helps
regards
David
On 23/07/2013 16:40, Henry Nash wrote:
Hi
As part of bp
https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target
I have uploaded some example WIP code showing a proposed approach for
just a few API calls (one easy, one more complex). I'd appreciate
early feedback on this before I take it any further.
https://review.openstack.org/#/c/38308/
A couple of points:
- One question is on how to handle errors when you are going to get a
target object before doing you policy check. What do you do if the
object does not exist? If you return NotFound, then someone, who was
not authorized could troll for the existence of entities by seeing
whether they got NotFound or Forbidden. If however, you return
Forbidden, then users who are authorized to, say, manage users in a
domain would aways get Forbidden for objects that didn't exist (since
we can know where the non-existant object was!). So this would
modify the expected return codes.
- I really think we need some good documentation on how to bud
keystone policy files. I'm happy to take a first cut as such a thing
- what do you think the right place is for such documentation
_______________________________________________ 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
