Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>