Open Stack

Hi Florian, I appreciate your post and sympathize with your 
frustration/confusion. I'll do my best below to help un-confuse :)

On 03/20/2012 12:15 PM, Florian Daniel Otel wrote:
> Hello all,
>
> I need some help with inconsistencies and -- in my mind -- confusing
> instructions wrt "auth_token" Keytone middleware.
>
> So far I have Keystone and Swift  w/ Keystone auth working well together
> (ussing Essex-4 milestone release  of Keystone resp v1.4.6 of Swift).
>
> What I am now  trying is to get  Glance on Swift with Keystone Auth  but
> I'm faced with conflicting info that I cannot make sense of
>
> 1) Naming inconsistencies -- "token_auth" , "tokenauth" (Keystone resp
> Swift) vs "authtoken"  (Glance)
>
> The existing Keystone and Swift docs (e.g. this one:
> http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone*)
> *use as names "token_auth" (Keystone) resp "tokenauth" (Swift)  wheareas
> in Glance docs the same midldleware (i.e.
> "keystone/middleware/auh_token.py") is referred to as "authtoken"  (see
> e.g.  here http://glance.openstack.org/authentication.html )
>
> While this may be only pedantic IMHO it would help if things would be
> called the same way in different places.  Or, if I'm confusing things,
> someone point me out the differences to which is what and why.

Completely agreed, and Chmouel has submitted two patches to address 
these inconsistencies.

> 2) "auth_token":  Persistent tokens or user/pass ?
>
> As per Jay Pipes comment here:
> https://bugs.launchpad.net/glance/+bug/953989/comments/2  (from
> 2012-03-13)  the concept of long-lived (i.e. persistent) tokens are no
> longer supported by the Keystone "auth_token" middleware  -- and that is
> listed as why that bug was invalid.

Actually, no not quite. The bug was marked Invalid because the source of 
the issue was three things that Kevin (the bug reporter) had failed to 
do in his setup -- two of which had to do with the authentication and 
one having to do with an incorrect endpoint template placeholder.

Anyway, let me try and explain what the deal is with the "long-lived 
token deprecation" that is mentioned in the bug report.

Previously in Keystone there was the concept of a "service token" -- 
otherwise known as a long-lived token. These special tokens would be 
read from a configuration file or paste-ini file by the auth_token 
middleware that sat, for instance, in the Glance API server pipeline. 
Importantly, these special tokens were **not required to be attached to 
any user or tenant**.

The auth_token middleware is responsible for authenticating -- via 
Keystone -- incoming regular user requests on an API endpoint. For 
example, if I call GET http://example.com:9292/v1/images to get a list 
of images from a Glance API server, and that server was configured with 
the auth_token middleware, then the middleware looks for certain HTTP 
headers in the incoming request.

If the HTTP_X_AUTH_TOKEN header is present in the incoming request,
then the middleware would need to *validate* this authentication token 
with Keystone. This validation call (POST /v2.0/tokens/{$token_id} [1]) 
is a *privileged* call in the Keystone Service Admin API, and as such, 
in order to make the validation request, the HTTP request to Keystone 
itself needs, itself, to supply an HTTP_X_AUTH_TOKEN that is "scoped" to 
some entity that can make this privileged validation call. However, as 
mentioned before, the long-lived "service token" was not scoped to any 
user/tenant, and these "unscoped" tokens were accepted by the validate 
token API call as privileged tokens...

OK, so recent changes removed this inconsistency in the scoping of 
tokens. There are no longer any tokens that are unscoped, and because of 
this, it was found to be more logical to have a user and password 
combination in middleware configuration files instead of a token. So, 
whereas you used to be able to just do:

[filter:authtoken]
...
admin_token = 998877665544

And have a long-lived "service token" with ID "998877665544" added to 
Keystone, you are no longer able to add an unscoped token. Instead, you 
don't add tokens manually at all. Instead, there are privileged user 
accounts that are in a service tenant, and these service user accounts 
are scoped to a set of privileged roles that enable the account to call 
privileged API calls such as POST /v2.0/tokens/{$token} in the Keystone 
Service Admin API.

So, now the middleware configuration looks like this:

[filter:authtoken]
...
service_user = glance
service_password = <SERVICE_PASSWORD>

And the auth_token middleware itself actually uses the user/password 
combination to retrieve a privileged token that the middleware stores in 
memory and uses when calling the token validation API calls.

Hope this long explanation makes things a bit more clear and hasn't 
further muddied the waters.

Best,
-jay

[1] 
http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1356.html