[openstack-dev] [keystone]how to get service_catalog

王华 wanghua.humble at gmail.com
Tue Sep 8 01:43:56 UTC 2015


Hi Jamie,

I find that when I use an existing token to fetch a new token with the same
rights (the expiry etc will be the same) , but keystone doesn't return
service_catalog in the response. I wonder why it is different from
authentication with password.

Regards,
Wanghua

On Tue, Sep 8, 2015 at 9:36 AM, 王华 <wanghua.humble at gmail.com> wrote:

> Hi Jamie,
>
> We want to reuse the user token in magnum. But there is no convenient way
> to reuse it. It is better that we can use ENV['keystone.token_auth'] to
> init keystoneclient directly. Now we need to construct a auth_ref which is
> a parameter in keystoneclient init function according to
> ENV['keystone.token_auth']. I think it is a common case which service wants
> to reuse user token to do something like getting service_catalog. Can
> keystoneclient provide this feature?
>
> Regards,
> Wanghua
>
> On Mon, Sep 7, 2015 at 12:54 PM, Jamie Lennox <jamielennox at redhat.com>
> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "王华" <wanghua.humble at gmail.com>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev at lists.openstack.org>
>> > Sent: Monday, 7 September, 2015 12:00:43 PM
>> > Subject: [openstack-dev] [keystone]how to get service_catalog
>> >
>> > Hi all,
>> >
>> > When I use a token to init a keystoneclient and try to get
>> service_catalog by
>> > it, error occurs. I find that keystone doesn't return service_catalog
>> when
>> > we use a token. Is there a way to get service_catalog by token? In
>> magnum,
>> > we now make a trick. We init a keystoneclient with service_catalog
>> which is
>> > contained in the token_info returned by keystonemiddleware in auth_ref
>> > parameter.
>> >
>> > I want a way to get service_catalog by token. Or can we init a
>> keystoneclient
>> > by the token_info return by keystonemiddleware directly?
>> >
>> > Regards,
>> > Wanghua
>>
>> Sort of.
>>
>> The problem you are hitting is that a token is just a string, an
>> identifier for some information stored in keystone. Given a token at
>> __init__ time the client doesn't try to validate this in anyway it just
>> assumes you know what you are doing. You can do a variation of this though
>> in which you use an existing token to fetch a new token with the same
>> rights (the expiry etc will be the same) and then you will get a fresh
>> service catalog. Using auth plugins that's the Token family of plugins.
>>
>> However i don't _think_ that's exactly what you're looking for in magnum.
>> What token are you trying to reuse?
>>
>> If it's the users token then auth_token passes down an auth plugin in the
>> ENV['keystone.token_auth'] variable[1] and you can pass that to a client to
>> reuse the token and service catalog. If you are loading up magnum specific
>> auth then again have a look at using keystoneclient's auth plugins and
>> reusing it across multiple requests.
>>
>> Trying to pass around a bundle of token id and service catalog is pretty
>> much exactly what an auth plugin does and you should be able to do
>> something there.
>>
>>
>> Jamie
>>
>> [1]
>> https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/__init__.py#L164
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150908/db9c7b55/attachment.html>


More information about the OpenStack-dev mailing list