Open Stack

Hi Arvind

thanks for pointing me to this issue, which I was not aware of. I have 
posted my twopence worth to the bug. Basically I agree with you, that if 
you want audit of third parties revoking tokens, then you need the token 
of the subject to be revoked and the third party requesting it.

regards

David

On 25/07/2013 16:18, Tiwari, Arvind wrote:
> 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.chadwick at 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:henryn at 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 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
>>>>>>>
>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>> OpenStack-dev mailing list
>>>>>>> OpenStack-dev at lists.openstack.org
>>>>>>> <mailto: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
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>>>
_______________________________________________
>>>> OpenStack-dev mailing list OpenStack-dev at 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 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
>>
>> _______________________________________________ OpenStack-dev
>> mailing list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>