Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/233829d3/attachment.html>