Open Stack

Generally speaking "A DoS from an authenticated user" is a _massive_
concern for anyone who has a cloud with unaccountable users, such as
shared clouds and for public clouds in particular.

-Rob

On 10/05/2013 19:58, "Dolph Mathews" <dolph.mathews at RACKSPACE.COM> wrote:

>Issuing a new token when a user asks for one is by design. I'm not sure
>that a DoS from an authenticated user is cause for concern.
>
>Suggestions: shorten token lifespan, cache your tokens client-side, flush
>expired tokens.
>
>-Dolph Mathews
>
>On May 10, 2013, at 12:00 PM, "Bhandaru, Malini K"
><malini.k.bhandaru at intel.com> wrote:
>
>> Adding keystone gurus  ayoung and dolphm to see if they can case some
>>light.
>> 
>> We can have multiple valid tokens in the system for a user, valid being
>>the operative word.
>> They are equal citizens with respect to access rights.
>> 
>> Regards
>> Malini
>> 
>> -----Original Message-----
>> From: Clark, Robert Graham [mailto:robert.clark at hp.com]
>> Sent: Friday, May 10, 2013 4:22 AM
>> To: Bhandaru, Malini K; openstack-security at lists.openstack.org
>> Subject: Re: [Openstack-security] keystone tokens
>> 
>> Does creating a new token on request invalidate the already issued
>>(Still
>> valid) tokens?
>> 
>> On 10/05/2013 00:44, "Bhandaru, Malini K" <malini.k.bhandaru at intel.com>
>> wrote:
>> 
>>> Greetings!!
>>> 
>>> Does anyone know why keystone design supports the creation of a fresh
>>> token for each time a user logs-in/requests a token Even if in the
>>> system there are un-expired tokens for the said user?
>>> Design justification?
>>> Apart from buggy code creating an explosion of tokens, this is a route
>>> for denial of service.
>>> Related bugs ..
>>> 
>>> https://bugs.launchpad.net/keystone/+bug/1168399
>>> https://bugs.launchpad.net/keystone/+bug/1178063
>>> 
>>> Regards
>>> Malini
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openstack-security mailing list
>>> Openstack-security at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>> 
>>