Thanks David. Since we are discussing authorization and access control, I would like to gain little attention on the below bug which basically propose authorization check on identity:check_token, identity:validate_token and identity:revoke_token APIs https://bugs.launchpad.net/keystone/+bug/1186059
Due to absence of a target on such API calls Auth is not possible, I would appreciate community's thoughts on the bug. Thanks, Arvind -----Original Message----- From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday, July 25, 2013 4:10 AM To: OpenStack Development Mailing List Cc: Tiwari, Arvind Subject: Re: [openstack-dev] [keystone] Extending policy checking to include target entities I have responded to your post, as I dont think it solves the identified problem regards David On 24/07/2013 23:26, Tiwari, Arvind wrote: > I have added my proposal @ > https://etherpad.openstack.org/api_policy_on_target. > > Thanks, > Arvind > > -----Original Message----- > From: Henry Nash [mailto:hen...@linux.vnet.ibm.com] > Sent: Wednesday, July 24, 2013 8:46 AM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [keystone] Extending policy checking to include > target entities > > I think we should transfer this discussion to the etherpad for this > blueprint: https://etherpad.openstack.org/api_policy_on_target > > I have summarised the views of this thread there already, so let's make any > further comments there, rather than here. > > Henry > On 24 Jul 2013, at 00:29, Simo Sorce wrote: > >> On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote: >>> ...the problem is that if the object does not exists we might not be able >>> tell whether the use is authorized or not (since authorization might depend >>> on attributes of the object itself)....so how do we know wether to lie or >>> not? >> >> If the error you return is always 'Not Found', why do you care ? >> >> Simo. >> >>> Henry >>> On 23 Jul 2013, at 21:23, David Chadwick wrote: >>> >>>> >>>> >>>> On 23/07/2013 19:02, Henry Nash wrote: >>>>> 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. >>>> >>>> I am not sure that this achieves your objective of no data leakage through >>>> error codes, does it? >>>> >>>> Its not a question of determining the correct answer or not, its a >>>> question of whether the user is authorised to see the correct answer or not >>>> >>>> regards >>>> >>>> David >>>>> >>>>> 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 >>>>>> <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@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 >>>>>> <mailto: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 >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >> _______________________________________________ >> 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
