Re: [openstack-dev] [Keystone] keystoneclient and project-less v3 tokens
On Tue, May 6, 2014 at 3:17 AM, Roman Bodnarchuk <
roman.bodnarc...@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@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
Re: [openstack-dev] [Keystone] keystoneclient and project-less v3 tokens
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@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
Re: [openstack-dev] [Keystone] keystoneclient and project-less v3 tokens
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
