[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