Open Stack

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/ac146e91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6186 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130619/ac146e91/attachment.bin>