Open Stack

On 07/25/2013 01:03 PM, Tiwari, Arvind wrote:
> Thanks David for your comments.
>
> I will try to fix it as per my suggestion in bug.
>
> Arvind
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick at kent.ac.uk]
> Sent: Thursday, July 25, 2013 10:27 AM
> To: Tiwari, Arvind
> Cc: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [keystone] Does authorization not needed on “/auth/tokens” API??
>
> 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

Agreed. I would argue that the larger issue is Audit in general, that 
certain APIs should be auditable, and that audit should be integrated 
with the policy checks.

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