Open Stack

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>