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