<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 6, 2014 at 3:17 AM, Roman Bodnarchuk <span dir="ltr"><<a href="mailto:roman.bodnarchuk@indigitus.ch" target="_blank">roman.bodnarchuk@indigitus.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thanks for reply. I think I got the justifications for such an approach.<br>
<br>
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?<br>
<br></blockquote><div><br></div><div>That's the goal of this blueprint, which will be discussing at the summit:</div><div><br></div><div> <a href="https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition">https://blueprints.launchpad.net/keystone/+spec/document-v2-to-v3-transition</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
--<br>
Roman<div class=""><div class="h5"><br>
<br>
On 4/28/2014 6:43 AM, Jamie Lennox wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Thu, 2014-04-17 at 19:58 +0300, Roman Bodnarchuk wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
I am trying to make sure that a user can't do anything useful with an<br>
unscoped token, and got to the following code in<br>
keystoneclient.middleware.<u></u>auth_token:<br>
<br>
if _token_is_v2(token_info) and not auth_ref.project_id:<br>
raise InvalidUserToken('Unable to determine tenancy.')<br>
<br>
This check is performed on every request, and successfully forbids any<br>
request authenticated by a project-less token. But only for v2 tokens!<br>
<br>
In case service is using v3 of Keystone api, the request successfully<br>
passes auth_token middleware filter, and it becomes the task of each<br>
specific service to handle unscopedness of passed token.<br>
<br>
While Nova seem to be handling this well (basing on several tests I<br>
made), I was able to fetch a list of available images from Glance using<br>
a token of projectless user.<br>
<br>
Is this a desired behavior of keystoneclient?<br>
Why do we check existence of project_id only for v2 tokens?<br>
<br>
Thanks,<br>
Roman<br>
</blockquote>
Hmm, that is fairly old code. Submitted before v3 tokens were even on<br>
the scene it looks like.<br>
<br>
As an educated guess here i expect that it's because a v3 token can be<br>
scoped to multiple things. It can be scoped to a project, a domain or a<br>
service - or not at all (which would be the same thing as scoping it to<br>
the keystone service).<br>
<br>
The more correct way to do this would be to enforce the need for a<br>
project scope on the service that requires the project scope. Not all<br>
services or all actions will need a project scope and there is no reason<br>
to prevent them access to the service if a project scope is unneeded.<br>
<br>
On the other hand whilst that is a good justification for leaving things<br>
as they are i'm guessing the _reason_ that it is enforced in v2 and some<br>
scope is not enforced in v3 is mostly an accident.<br>
<br>
<br>
Jamie<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>