Thanks for reply. I think I got the justifications for such an approach.
BTW, is there a resource, which can be used to track support of Keystone
v3 (and domain-based policies) among OS services? Are there some
defined plans for moving whole OS to v3 and domains?
--
Roman
On 4/28/2014 6:43 AM, Jamie Lennox wrote:
On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:
Hello,
I am trying to make sure that a user can't do anything useful with an
unscoped token, and got to the following code in
keystoneclient.middleware.auth_token:
if _token_is_v2(token_info) and not auth_ref.project_id:
raise InvalidUserToken('Unable to determine tenancy.')
This check is performed on every request, and successfully forbids any
request authenticated by a project-less token. But only for v2 tokens!
In case service is using v3 of Keystone api, the request successfully
passes auth_token middleware filter, and it becomes the task of each
specific service to handle unscopedness of passed token.
While Nova seem to be handling this well (basing on several tests I
made), I was able to fetch a list of available images from Glance using
a token of projectless user.
Is this a desired behavior of keystoneclient?
Why do we check existence of project_id only for v2 tokens?
Thanks,
Roman
Hmm, that is fairly old code. Submitted before v3 tokens were even on
the scene it looks like.
As an educated guess here i expect that it's because a v3 token can be
scoped to multiple things. It can be scoped to a project, a domain or a
service - or not at all (which would be the same thing as scoping it to
the keystone service).
The more correct way to do this would be to enforce the need for a
project scope on the service that requires the project scope. Not all
services or all actions will need a project scope and there is no reason
to prevent them access to the service if a project scope is unneeded.
On the other hand whilst that is a good justification for leaving things
as they are i'm guessing the _reason_ that it is enforced in v2 and some
scope is not enforced in v3 is mostly an accident.
Jamie
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
