I really want to go the other way on this: I want token to be very
short lived, ideally something like 1 minute, but probably 5 minutes to
account for clock skew. I want to get rid of token revocation list
checking. I'd like to get away from revocation altogether: tokens are
not stored in the backend. If they are ephemeral, we can just check
that the token has a valid signature and that the time has not expired.
On 06/19/2013 12:59 PM, Ravi Chunduru wrote:
Thats still an open item in this thread.
Let me summarize once again
1) Use case for keystone not to re-issue same token for same credentials
2) Ratelimit cons and service unavailability
3) Further information on python keyring if not going by keystone
re-issue of the tokens.
On Wed, Jun 19, 2013 at 9:16 AM, Yee, Guang <[email protected]
<mailto:[email protected]>> wrote:
Just out of curiosity, is there really a use case where user need
to request multiple tokens of the same scope, where the only
difference are the expiration dates?
Guang
*From:*Dolph Mathews [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Wednesday, June 19, 2013 7:27 AM
*To:* OpenStack Development Mailing List
*Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
On Wed, Jun 19, 2013 at 1:42 AM, Ali, Haneef <[email protected]
<mailto:[email protected]>> wrote:
1)Token Caching is not always going to help. It depends on the
application. E.g A user writes a cron job to check the
health of swift by listing a predefined container every 1 minute.
This will obviously create a token every minute.
2)Also I like to understand how rate limiting is done for v3
tokens. Rate limiting involves source ip + request pattern. In
V3 there are so many ways to get the token and the rate limiting
becomes too complex
Rate limit the number of requests to POST /v2.0/tokens and POST
/v3/auth/tokens
Just for unscoped token, all the following are equivalent
requests. In case of scoped tokens we have even more
combinations. Rouge clients can easily mess with rate
limiting by mixing request patterns. Also rate limiting across
regions may not be possible.
a. UserId/Password
b. UserName/Password/domainId
c.UserName/Password/DomainName
Thanks
Haneef
*From:*Ravi Chunduru [mailto:[email protected]
<mailto:[email protected]>]
*Sent:* Tuesday, June 18, 2013 11:02 PM
*To:* OpenStack Development Mailing List
*Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
I agree we need a way to overcome these rogue clients but by
rate limiting genuine requests will get effected. Then one
would need retries and some times critical operations gets
failed. It beats the whole logic of being available.
About the keyrings, How do we tackle if a service is using
JSON API calls and not python clients?
Thanks,
-Ravi.
On Tue, Jun 18, 2013 at 6:37 PM, Adam Young <[email protected]
<mailto:[email protected]>> wrote:
On 06/18/2013 09:13 PM, Kant, Arun wrote:
The issue with having un-managed number of tokens for same
credential is that it can be easily exploited. Getting a
token is one of initial step (gateway) to get access to
services. A rogue client can keep creating unlimited
number of tokens and possibly create denial of service
attack on services. If there are somewhat limited number
of tokens, then cloud provider can possibly use tokenId
based rate-limiting approach.
Better here to rate limit, then.
Extending the expiry to some fixed interval might be okay as
that can be considered as continuing user session similar to
what is seen when a user keeps browsing an application while
logged in.
Tokens are resources created by Keystone. No reason to ask to
create something new if it is not needed.
The caching needs to be done client side. We have ongoing
work using python-keyring to support that.
-Arun
*From: *Adam Young <[email protected] <mailto:[email protected]>>
*Reply-To: *OpenStack Development Mailing List
<[email protected]
<mailto:[email protected]>>
*Date: *Friday, June 14, 2013 3:33 PM
*To: *"[email protected]
<mailto:[email protected]>"
<[email protected]
<mailto:[email protected]>>
*Subject: *Re: [openstack-dev] [Keystone][Folsom] Token re-use
On 06/13/2013 07:58 PM, Ravi Chunduru wrote:
Hi,
We are having Folsom setup and we find that our token
table increases a lot. I understand client can re-use the
token but why doesnt keystone reuse the token if client
asks it with same credentials..
I would like to know if there is any reason for not doing so.
Thanks in advance,
--
Ravi
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
You can cache the token on the client side and reuse. Tokens
have a an expiry, so if you request a new token, you extend
the expiry.
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ravi
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Ravi
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
