On 23/07/2013 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.
Yes its my verbiage. But the concept is not. The concept was "tell an
unauthorised user the same answer regardless of whether the object
exists or not, so that he cannot gain information from leakage through
error codes".
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.
yes that conforms to the general principle.
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.
Yes, so that the authorised person gets information but the unauthorised
one does not
regards
David
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
_______________________________________________
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
