openstack team mailing list archive

[Deepak Garg <deepakgarg.iitg@xxxxxxxxx>]

HI Florian,

The name of apps/middleware in wsgi pipeline doesn't matter unless the
location pointed by paste.app_factory or
paste.filter_factory remains the same. So, the following two
configurations are same:

----------------------------------------------------------------------------------------------------
[pipeline:main]
pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server

[filter:tokenauth]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
[pipeline:main]
pipeline = catch_errors healthcheck cache authtoken keystone proxy-server

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
------------------------------------------------------------------------------------------

Please notice that I have just replaced the word 'tokenauth' with
'authtoken'. We may even use the
word 'magictoken' without making any difference as long as the
middleware pointed by "paste.filter_factory =
keystone.middleware.auth_token:filter_factory"  remains the same.

Now whenever you use a nova/swift/quantum cli and pass a token with
it, the corresponding service (say nova in this case)
verifies your passed token with Keystone. Now Keystone needs to be
assured that the service making the 'token validation call'
is a valid one. So it uses the admin_token and other credentials saved
in the conf file of that particular service to get an admin token
and then make a call (using the admin token) to verify the user token.


Hope it answers both of your questions.


Cheers,
Deepak





On Tue, Mar 20, 2012 at 9:45 PM, Florian Daniel Otel
<florian.otel@xxxxxxxxx> 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.
>
> 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.
>
> Now, that gets me _really_ confused: My working Keystone (again, as per E4)
> + Swift (as per v1.4.6) use persistent tokens just fine. E.g. my WSGI
> pipleline for the swift proxy server looks like this:
>
> [pipeline:main]
> pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server
>
> ......
> with  the corresponding:
>
> ...
> [filter:keystone]
> paste.filter_factory = keystone.middleware.swift_auth:filter_factory
> operator_roles = admin, SwiftOperator
>
> [filter:tokenauth]
> paste.filter_factory = keystone.middleware.auth_token:filter_factory
> service_protocol = http
> service_port = 5000
> service_host = 127.0.0.1
> auth_port = 5001
> auth_host = 127.0.0.1
> admin_token = 999888777666
> delay_auth_decision = 0
> ...
>
> Now, the question is: Since we are now to stop using long-lived tokens
> hardcoded as "admin_token" in "keystone.conf", resp in the "auth_token"
> middleware sections of swift resp, glance, how is a user/pass config
> supposed to look  like  ? examples ?
>
> Sorry if this question is not as clearly laid out is it should be, reason is
> this is all very confusing to me .... (maybe time for me to get a rubber
> ducky and explain it all ...)
>
> Thanks in advance for the help,
>
> Florian
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Deepak Garg,
Data Center and Cloud Div.
Citrix R&D, India
Skype-id: deepakgarg.iit