Open Stack

+1

On Thu, Jun 20, 2013 at 11:37 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

>
> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130620/b912ae39/attachment.html>