openstack team mailing list archive

[Florian Daniel Otel <florian.otel@xxxxxxxxx>]

Thanks Jay for the in-depth explanation, it actually does make sense :)

Sorry for the late reply -- I had to to change my Keystone, Swift and
Glance setup and digest the changes. Still not completely out of the woods
yet....

Thanks Chmouel for the the patch [1]  for the Glance and Swift config
files. It's pretty much what I had in mind as well. However, shouldn't
"keystone.conf" itself be changed accordingly  ? I can take a stab at it
and submit a proposal if it helps...

Also, wrt to the docs [2]. AFAICT the patch covers only
"doc/sources/configuringservices.rst" , but it needs fixing in other places
too (e.g. "doc/sources/middleware_architecture.rst").  Same thing there --
I can try to make a patch and submit it (I need to get the hang of it
first...)

Regards,

Florian

[1]
https://github.com/openstack-dev/devstack/commit/bd07d61c4545c52d39b9c957ff9e4423525ca452
[2] https://review.openstack.org/#change,5190



On Tue, Mar 20, 2012 at 10:09 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:

> 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*<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<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<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<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<http://docs.openstack.org/api/openstack-identity-service/2.0/content/GET_validateToken_v2.0_tokens__tokenId__Admin_API_Service_Developer_Operations-d1e1356.html>
>
>
> ______________________________**_________________
> Mailing list: https://launchpad.net/~**openstack<https://launchpad.net/%7Eopenstack>
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~**openstack<https://launchpad.net/%7Eopenstack>
> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>