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
> 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
