Open Stack

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