One thing we could do is: - Return Forbidden or NotFound if we can determine the correct answer - When we can't (i.e. the object doesn't exist), then return NotFound unless a new config value 'policy_harden' (?) is set to true (default false) in which case we translate NotFound into Forbidden.
Henry On 23 Jul 2013, at 18:31, Adam Young wrote: > 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 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
