On Thu, Aug 1, 2013 at 12:43 AM, Jay Pipes <[email protected]> wrote:
> I have a question for the auth_token middleware developers. > > The default auth_port is set to 35357, which is the admin API port for > Keystone: > > https://github.com/openstack/**python-keystoneclient/blob/** > master/keystoneclient/**middleware/auth_token.py#L201<https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L201> 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): https://review.openstack.org/#/c/34430/ ). There's two use cases for the 'auth_*' options in auth_token. 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) 2) Allow auth_token to communicate with keystone for token validation, etc, at an administrative level (this *requires* the port 35357 admin API endpoint) 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). The second use case explicitly requires the admin API because v2.0 public/service API (GET :5000/v2.0/tokens) is not supported. > > > 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. > > 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? Yes! We need to immediately start logging a warning if this conditional is met: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L287-L290 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: https://bugs.launchpad.net/python-keystoneclient/+bug/1207517 auth_uri => point at public API endpoint in support of use case #1 above auth_host, auth_port, auth, auth_protocol, auth_admin_prefix => point at admin API in support of use case #2 above Documentation fixes for the above, plus a warning log if auth_uri is not set: https://review.openstack.org/#/c/39796/ > I'm having a heck of a time tracking down the source of this bug: > > https://bugs.launchpad.net/**nova/+bug/1206330<https://bugs.launchpad.net/nova/+bug/1206330> > > And am trying to cross any possible configuration issues with the > auth_token middleware off of my list of possible causes. > > Any and all insight would be most appreciated. > > Best, > -jay > > ______________________________**_________________ > OpenStack-dev mailing list > [email protected].**org <[email protected]> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > -- -Dolph
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
