+1 On Thu, Jun 20, 2013 at 11:37 AM, Dolph Mathews <[email protected]>wrote:
> > On Wed, Jun 19, 2013 at 2:20 PM, Adam Young <[email protected]> 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 <[email protected]> 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:[email protected]] >>> *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 <[email protected]> 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:[email protected]] >>> *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 <[email protected]> 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 <[email protected]> >>> *Reply-To: *OpenStack Development Mailing List < >>> [email protected]> >>> *Date: *Friday, June 14, 2013 3:33 PM >>> *To: *"[email protected]" < >>> [email protected]> >>> *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 >>> >>> [email protected]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 >>> >>> [email protected] >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> >>> -- >>> Ravi >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Ravi >> >> >> _______________________________________________ >> OpenStack-dev mailing >> [email protected]http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Ravi
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
