On 01/31/2013 10:57 PM, Vishvananda Ishaya wrote:
On Jan 31, 2013, at 6:37 PM, "Ali, Haneef" <[email protected]
<mailto:[email protected]>> 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:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>]*On Behalf
Of*Adam Young
*Sent:*Thursday, January 31, 2013 6:25 PM
*To:*[email protected] <mailto:[email protected]>
*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 :[email protected]
<mailto:[email protected]>
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 : [email protected]
<mailto:[email protected]>
Unsubscribe : https://launchpad.net/~openstack
<https://launchpad.net/%7Eopenstack>
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
