Open Stack

On Thu, Aug 1, 2013 at 12:43 AM, Jay Pipes <jaypipes at gmail.com> 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
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130801/f978a105/attachment.html>