When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
So applying this approach to your situation, you could reply Not Found
to people who are authorised to see the object if it had existed but
does not, and Not Found to those not authorised to see it, regardless of
whether it exists or not. In this case, only those who are authorised to
see the object will get it if it exists. Those not authorised cannot
tell the difference between objects that dont exist and those that do exist
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
