<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 1, 2013 at 12:43 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</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">I have a question for the auth_token middleware developers.<br>

<br>
The default auth_port is set to 35357, which is the admin API port for Keystone:<br>
<br>
<a href="https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L201" target="_blank">https://github.com/openstack/<u></u>python-keystoneclient/blob/<u></u>master/keystoneclient/<u></u>middleware/auth_token.py#L201</a></blockquote>
<div><br></div><div>I'm going to chalk this one up to an existing lack of documentation, a situation which happens to be vastly improved by (but not at all rectified by): <a href="https://review.openstack.org/#/c/34430/">https://review.openstack.org/#/c/34430/</a> ).</div>
<div><br></div><div>There's two use cases for the 'auth_*' options in auth_token.</div><div><br></div><div>1) Direct unauthenticated clients to the public/service API in order to authenticate, so that they can return with a valid token (this *requires* the port 5000 public/service API endpoint)</div>
<div><br></div><div>2) Allow auth_token to communicate with keystone for token validation, etc, at an administrative level (this *requires* the port 35357 admin API endpoint)</div><div><br></div><div>The first use case explicitly requires the public API endpoint due to the "long" authentication flow on v2.0 (where the client has no default tenancy and must retrieve a list of tenants) as the GET :5000/v2.0/tenants (intended for users to list tenants they have explicit access to) will return a completely different response to GET :35357/v2.0/tenants (intended for admins to list all tenants in the system).<br>
</div><div><br></div><div>The second use case explicitly requires the admin API because v2.0 public/service API (GET :5000/v2.0/tokens) is not supported.</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>
<br>
However, the token validation API call (POST /v2.0/tokens or POST /v3/auth/tokens) uses the *service* API port, not the admin API port... in fact, in the v3 API, there is no longer any distinction (thankfully) between the service API and the admin API ... it's all just one API.<br>
</blockquote><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>
So, my question is this: we've been setting all of the auth_token config options to the 5000 port -- the service API port for v2.0 Keystone. Is this problematic?</blockquote><div><br></div><div>Yes! We need to immediately start logging a warning if this conditional is met:</div>
<div><br></div><div>  <a href="https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L287-L290">https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L287-L290</a></div>
<div><br></div><div>This appears to be providing some lazy support for a broken configuration? Regardless, this behavior should not be supported by auth_token (and as explained above, keystone doesn't support it). I opened a bug to track a fix:<br>
</div><div><br></div><div>  <a href="https://bugs.launchpad.net/python-keystoneclient/+bug/1207517">https://bugs.launchpad.net/python-keystoneclient/+bug/1207517</a></div><div><br></div><div>auth_uri => point at public API endpoint in support of use case #1 above</div>
<div><br></div><div>auth_host, auth_port, auth, auth_protocol, auth_admin_prefix => point at admin API in support of use case #2 above</div><div><br></div><div>Documentation fixes for the above, plus a warning log if auth_uri is not set:</div>
<div><br></div><div>  <a href="https://review.openstack.org/#/c/39796/">https://review.openstack.org/#/c/39796/</a><br></div><div> <br></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">
I'm having a heck of a time tracking down the source of this bug:<br>
<br>
<a href="https://bugs.launchpad.net/nova/+bug/1206330" target="_blank">https://bugs.launchpad.net/<u></u>nova/+bug/1206330</a><br>
<br>
And am trying to cross any possible configuration issues with the auth_token middleware off of my list of possible causes.<br>
<br>
Any and all insight would be most appreciated.<br>
<br>
Best,<br>
-jay<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></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>