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