Open Stack

Interesting approach. 

I've just been looking at the patch to fix the issue in keystone
(https://review.openstack.org/#/c/39878/) and it looks reasonably sound.


Do you find it a lot of work to have the various projects polling?

> -----Original Message-----
> From: Jarret Raim [mailto:jarret.raim at RACKSPACE.COM]
> Sent: 07 August 2013 13:42
> To: Clark, Robert Graham; openstack-security at lists.openstack.org
> Subject: Re: [Openstack-security] [OSSN][DRAFT] Disabling a tenant
does
> not disable a user token
> 
> At Rackspace, we've attempted to mitigate this be requiring products
that
> want to cache user tokens to listen to an ATOM feed that our identity
> system exposes that tracks user state changes. When a tenant is
disabled, a
> message appears on the ATOM feed, which the products use to invalidate
> the cache entry.
> 
> It's not super great (ATOM is still polling), but it does allow some
guarantee
> that an existing token will get revoked within x minutes from
invalidation,
> usually less than 5.
> 
> 
> I think this functionality is build into repose, our rest proxy. It's
open source
> if people want to poke at it:
> 
> http://openrepose.org/
> 
> 
> 
> Jarret
> 
> 
> 
> 
> On 8/7/13 7:33 AM, "Clark, Robert Graham" <robert.clark at hp.com> wrote:
> 
> >[DRAFT] - Please Review
> >Disabling a tenant does not disable a user token
> >----
> >
> >### Summary ###
> >When a tenant is disabled in Keystone, tokens that have been issued
to
> >that tenant are not invalidated. This can result in users having
access
> >to your cloud after you have attempted to revoke them.
> >
> >### Affected Services / Software ###
> >Keystone
> >
> >### Discussion ###
> >It appears that Keystone does not purge the tokens given out to
tenants
> >when a tenant is disabled. In some scenarios this could be very
> >important to cloud providers. Take the case where a cloud provider
must
> >a tenant's access because of some legal investigation. Even though
the
> >tenant is disabled it would be possible for them to terminate VMs /
> >delete Swift files etc. - There are many other abuse-cases...
> >
> >### Recommended Actions ###
> >How the tokens are stored depends on your cloud deployment. If you
> >deploy using Memcache to back Keystone then flushing the cash when
> >disabling a token would resolve this issue for you, at the cost of
> >other token lookups which are no longer in the cash requiring
Keystone
> >interaction.
> >
> >It is of course possible to script something to remove tokens from
any
> >backend DB or cache but there is no 'official' way to do this.
> >
> >### Contacts / References ###
> >Proposed Fix : https://review.openstack.org/#/c/39878/
> >This OSSN : https://bugs.launchpad.net/ossn/+bug/1179955
> >OpenStack Security ML : openstack-security at lists.openstack.org
> >OpenStack Security Group : https://launchpad.net/~openstack-ossg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20130807/9d74db66/attachment.bin>