[openstack-dev] [keystone] Extending policy checking to include target entities
ayoung at redhat.com
Tue Jul 23 17:31:40 UTC 2013
On 07/23/2013 12:54 PM, David Chadwick wrote:
> When writing a previous ISO standard the approach we took was as follows
> Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would like
to get the attribution correct.
> 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
So, to try and apply this to a semi-real example: There are two types
of URLs. Ones that are like this:
and ones like this:
In the first case, you are selecting against a global collection, and in
the second, against a scoped collection.
For unscoped, you have to treat all users as equal, and thus a 404
probably makes sense.
For a scoped collection we could return a 404 or a 403 Forbidden
<https://en.wikipedia.org/wiki/HTTP_403> based on the users
credentials: all resources under domain/66DEADBEEF0000 would show up
as 403s regardless of existantce or not if the user had no roles in the
domain 66DEADBEEF0000. A user that would be allowed access to resources
in 66DEADBEEF0000 would get a 403 only for an object that existed but
that they had no permission to read, and 404 for a resource that doesn't
> On 23/07/2013 16:40, Henry Nash wrote:
>> As part of bp
>> 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.
>> 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
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev