Open Stack

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:

users/55FEEDBABECAFE

and ones like this:

domain/66DEADBEEF0000/users/55FEEDBABECAFE


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130723/aaab7a86/attachment.html>