[Openstack] [keystone] Why are we returing such a big payload in validate token?
Adam Young
ayoung at redhat.com
Fri Feb 1 04:32:44 UTC 2013
On 01/31/2013 10:57 PM, Vishvananda Ishaya wrote:
> On Jan 31, 2013, at 6:37 PM, "Ali, Haneef" <haneef.ali at hp.com
> <mailto:haneef.ali at hp.com>> wrote:
>
>> Isn’t signed token an optional feature? If so validateToken is
>> going to be a high frequency call. Also “Service Catalog” is a
>> constant, the services can cache it. It doesn’t need to be part of
>> validateToken.
>
> Service catalog is not a constant. That said the only time it is used
> is when a service needs to proxy a call to another service using the
> same token. If we had a reasonable way to make requests on behalf of
> other users we don't really need it as the service could just keep its
> own catalog and make requests on behalf of the requesting user.
I'm working on it. It is called "trusts" and there is a WIP posted here:
https://review.openstack.org/#/c/20289/
Blueprint is here:
https://blueprints.launchpad.net/keystone/+spec/trusts
>
> Vish
>
>> Thanks
>> Haneef
>> *From:*openstack-bounces+haneef.ali=hp.com at lists.launchpad.net
>> <mailto:openstack-bounces+haneef.ali=hp.com at lists.launchpad.net>
>> [mailto:openstack-bounces+haneef.ali=hp.com at lists.launchpad.net
>> <mailto:bounces+haneef.ali=hp.com at lists.launchpad.net>]*On Behalf
>> Of*Adam Young
>> *Sent:*Thursday, January 31, 2013 6:25 PM
>> *To:*openstack at lists.launchpad.net <mailto:openstack at lists.launchpad.net>
>> *Subject:*Re: [Openstack] [keystone] Why are we returing such a big
>> payload in validate token?
>> On 01/31/2013 07:44 PM, Ali, Haneef wrote:
>>
>> Hi,
>> As of now v3 validateToken response has “tokens, service
>> catalog, users, project , roles and domains. (i.e) Except for
>> groups we are returning everything. We also discussed about the
>> possibility of 100s of endpoints. ValidateToken is supposed to
>> be a high frequency call . This is
>>
>>
>> Validate token should not going be a high frequency call. The
>> information is encapsulated inside the signed token for just that reason.
>>
>> I would agree with the sentiment, however, that we are cramming a lot
>> of info into the token. TOkens should be scoped much, much more
>> finely: by default one service or endpoint, and one tenant.
>>
>> The only thing that should require the full service catalog is the
>> initial request of an unsigned token, and that should merely go back
>> to the client.
>>
>>
>> going to be a huge performance impact . What is the use case for
>> such a big payload when compared with v2?
>> If a service needs catalog , then the service can always ask for the
>> catalog.
>> Thanks
>> Haneef
>>
>>
>>
>> _______________________________________________
>> Mailing list:https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack>
>> Post to :openstack at lists.launchpad.net <mailto:openstack at lists.launchpad.net>
>> Unsubscribe :https://launchpad.net/~openstack <https://launchpad.net/%7Eopenstack>
>> More help :https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> <https://launchpad.net/%7Eopenstack>
>> Post to : openstack at lists.launchpad.net
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> <https://launchpad.net/%7Eopenstack>
>> More help : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130131/91aae6d5/attachment.html>
More information about the Openstack
mailing list