Open Stack

On Tue, May 6, 2014 at 3:17 AM, Roman Bodnarchuk <
roman.bodnarchuk at indigitus.ch> wrote:

> 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?
>
>
That's the goal of this blueprint, which will be discussing at the summit:


https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition


> --
> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140506/fa9ed35d/attachment.html>