Open Stack

On Wed, Jun 19, 2013 at 2:20 PM, Adam Young <ayoung at redhat.com> wrote:

>  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.
>

+10


>
>
>
>
>
>
> 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> 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]
>> *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> 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]
>> *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> 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>
>> *Reply-To: *OpenStack Development Mailing List <
>> openstack-dev at lists.openstack.org>
>> *Date: *Friday, June 14, 2013 3:33 PM
>> *To: *"openstack-dev at lists.openstack.org" <
>> 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.orghttp://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
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> 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
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
>  --
> Ravi
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20130620/71b68d13/attachment.html>