openstack team mailing list archive

[Joseph Heck <heckj@xxxxxx>]

Florian - 

Would love to have some docs patches!

-joe

On Mar 23, 2012, at 6:04 AM, Florian Daniel Otel wrote:

> 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*)
> *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
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp