[openstack-dev] FW: [Keystone][Folsom] Token re-use
Adam Young
ayoung at redhat.com
Wed Jun 19 19:20:48 UTC 2013
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 <guang.yee at hp.com
> <mailto:guang.yee at hp.com>> 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:dolph.mathews at gmail.com
> <mailto:dolph.mathews at gmail.com>]
> *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 <haneef.ali at hp.com
> <mailto:haneef.ali at hp.com>> 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:ravivsn at gmail.com
> <mailto:ravivsn at gmail.com>]
> *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 <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> 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 <ayoung at redhat.com <mailto:ayoung at redhat.com>>
> *Reply-To: *OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> *Date: *Friday, June 14, 2013 3:33 PM
> *To: *"openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>"
> <openstack-dev at lists.openstack.org
> <mailto:openstack-dev at lists.openstack.org>>
> *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
>> OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>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
>> OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> --
> Ravi
>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> --
> Ravi
>>> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130619/7f186f5f/attachment.html>
More information about the OpenStack-dev
mailing list