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 <jaypi...@gmail.com> 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@lists.launchpad.net > Unsubscribe : > https://launchpad.net/~**openstack<https://launchpad.net/%7Eopenstack> > More help : > https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
