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