Disabling a tenant would not disable a user token

Bug #1179955 reported by Chmouel Boudjnah on 2013-05-14
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Keystone
High
Chmouel Boudjnah
Folsom
High
Dolph Mathews
Grizzly
High
Dolph Mathews
OpenStack Security Notes
High
Robert Clark
keystone (Gentoo Linux)
Fix Released
Low

Bug Description

Using keystone/python-keystoneclient master as of today when disabling a tenant would not disable the users attached to the and would still have access.

I would not mind to fix it but I want to make sure first if this is something done by design or I am missing something.

Here is a transcript of my tests :

# Here is the list of my tenants all enabled and nice (devstack default)
chmouel@vm:~$ keystone tenant-list
+----------------------------------+--------------------+---------+
| id | name | enabled |
+----------------------------------+--------------------+---------+
| 1f1aeeace0db41e3966a4873877c4dde | admin | True |
| b39f8b007abe472b93ebb5c7fdd80c98 | demo | True |
| 64e78275f80d47f998c4cd1f06e79b1e | invisible_to_admin | True |
| 13fe49ee5e0144d0acd0c89fb901a248 | service | True |
+----------------------------------+--------------------+---------+

# Let's store the DEMO_TENANT_ID for later
chmouel@vm:~$ DEMO_TENANT=b39f8b007abe472b93ebb5c7fdd80c98

# getting a token with this script available here http://p.chmouel.com/ks which
chmouel@vm:~$ ks localhost demo:demo ADMIN
[...]

# Using the token I can access to my swift account properly all good here.
chmouel@vm:~$ curl -i -H 'X-Auth-Token: b4b6fb5426914e19bc45cc7780be9b59' http://172.16.129.140:8080/v1/AUTH_b39f8b007abe472b93ebb5c7fdd80c98
HTTP/1.1 204 No Content
Content-Length: 0
Accept-Ranges: bytes
X-Timestamp: 1368532646.31643
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
Content-Type: text/html; charset=UTF-8
X-Account-Object-Count: 0
X-Trans-Id: tx390b2fb557fb4cb48a082-0051923f3b
Date: Tue, 14 May 2013 13:42:19 GMT

# Now let's try to disable that tenant
chmouel@vm:~$ keystone tenant-update --enabled false ${DEMO_TENANT}

# tenant is disabled all good
chmouel@vm:~$ keystone tenant-list
+----------------------------------+--------------------+---------+
| id | name | enabled |
+----------------------------------+--------------------+---------+
| 1f1aeeace0db41e3966a4873877c4dde | admin | True |
| b39f8b007abe472b93ebb5c7fdd80c98 | demo | False |
| 64e78275f80d47f998c4cd1f06e79b1e | invisible_to_admin | True |
| 13fe49ee5e0144d0acd0c89fb901a248 | service | True |
+----------------------------------+--------------------+---------+

# we still have access with that same token since it's properly in memcache
chmouel@vm:~$ curl -i -H 'X-Auth-Token: b4b6fb5426914e19bc45cc7780be9b59' http://172.16.129.140:8080/v1/AUTH_b39f8b007abe472b93ebb5c7fdd80c98
HTTP/1.1 204 No Content
Content-Length: 0
Accept-Ranges: bytes
X-Timestamp: 1368532646.31643
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
Content-Type: text/html; charset=UTF-8
X-Account-Object-Count: 0
X-Trans-Id: txf9d27a7a8a034304b13cb-0051923f6f
Date: Tue, 14 May 2013 13:43:11 GMT

# let's restart memcache to clear it
chmouel@vm:~$ sudo /etc/init.d/memcached restart
Restarting memcached: memcached.

# but we still have access.
chmouel@vm:~$ curl -i -H 'X-Auth-Token: b4b6fb5426914e19bc45cc7780be9b59' http://172.16.129.140:8080/v1/AUTH_b39f8b007abe472b93ebb5c7fdd80c98
HTTP/1.1 204 No Content
Content-Length: 0
Accept-Ranges: bytes
X-Timestamp: 1368532646.31643
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
Content-Type: text/html; charset=UTF-8
X-Account-Object-Count: 0
X-Trans-Id: txbe0c0caf533a4f6e98345-0051923f97
Date: Tue, 14 May 2013 13:43:51 GMT

the json reply when validating token says that the tenant is still enabled even if it's disabled :

u'tenant': {u'description': None, u'enabled': True, u'id': u'b39f8b007abe472b93ebb5c7fdd80c98', u'name': u'demo'}}

Thierry Carrez (ttx) wrote :

Adding Keystone core devs to discuss.

There has been some bugs files already about disabling / deleting tenants and how that should propagate to tenant-related resources, so I'm not 100% sure that would constitute a vulnerability.

Changed in keystone:
status: New → Invalid
Chmouel Boudjnah (chmouel) wrote :

FYI: I have just figured out that my tokens were stored in mysql DB so clearing them (or using memcached tokens) would get the tokens properly invalided after update.

I still believe there is a bug that we need to delete the token belonging to the tenants when we update it in :

https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L108

like done for users :

https://github.com/openstack/keystone/blob/master/keystone/identity/controllers.py#L220

I think we can remove the security issue tag (but that's definitvely a bug) since this can be workarounded but I would like some feedback from keystone core devs first.

Changed in keystone:
status: Invalid → Confirmed
information type: Private Security → Public
Changed in keystone:
assignee: nobody → Satyanarayana Patibandla (satya-patibandla)
Dolph Mathews (dolph) on 2013-06-03
Changed in keystone:
importance: Undecided → Critical

Fix proposed to branch: master
Review: https://review.openstack.org/31564

Changed in keystone:
assignee: Satyanarayana Patibandla (satya-patibandla) → Dolph Mathews (dolph)
status: Confirmed → In Progress
Dolph Mathews (dolph) on 2013-06-04
information type: Public → Public Security
Dolph Mathews (dolph) wrote :

satya-patibandla: didn't mean to hijack this if you have a solution. I just wanted to put tests up to demonstrate

Download full text (4.7 KiB)

If the token is tenant scoped .. would make sense to disable token?

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Dolph Mathews
Sent: Tuesday, June 04, 2013 2:21 PM
To: Bhandaru, Malini K
Subject: [Bug 1179955] Re: Disabling a tenant would not disable a user token

satya-patibandla: didn't mean to hijack this if you have a solution. I just wanted to put tests up to demonstrate

--
You received this bug notification because you are subscribed to Keystone.
Matching subscriptions: keystone
https://bugs.launchpad.net/bugs/1179955

Title:
  Disabling a tenant would not disable a user token

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  Using keystone/python-keystoneclient master as of today when disabling
  a tenant would not disable the users attached to the and would still
  have access.

  I would not mind to fix it but I want to make sure first if this is
  something done by design or I am missing something.

  Here is a transcript of my tests :

  # Here is the list of my tenants all enabled and nice (devstack default)
  chmouel@vm:~$ keystone tenant-list
  +----------------------------------+--------------------+---------+
  | id | name | enabled |
  +----------------------------------+--------------------+---------+
  | 1f1aeeace0db41e3966a4873877c4dde | admin | True |
  | b39f8b007abe472b93ebb5c7fdd80c98 | demo | True |
  | 64e78275f80d47f998c4cd1f06e79b1e | invisible_to_admin | True |
  | 13fe49ee5e0144d0acd0c89fb901a248 | service | True |
  +----------------------------------+--------------------+---------+

  # Let's store the DEMO_TENANT_ID for later
  chmouel@vm:~$ DEMO_TENANT=b39f8b007abe472b93ebb5c7fdd80c98

  # getting a token with this script available here http://p.chmouel.com/ks which
  chmouel@vm:~$ ks localhost demo:demo ADMIN
  [...]

  # Using the token I can access to my swift account properly all good here.
  chmouel@vm:~$ curl -i -H 'X-Auth-Token: b4b6fb5426914e19bc45cc7780be9b59' http://172.16.129.140:8080/v1/AUTH_b39f8b007abe472b93ebb5c7fdd80c98
  HTTP/1.1 204 No Content
  Content-Length: 0
  Accept-Ranges: bytes
  X-Timestamp: 1368532646.31643
  X-Account-Bytes-Used: 0
  X-Account-Container-Count: 0
  Content-Type: text/html; charset=UTF-8
  X-Account-Object-Count: 0
  X-Trans-Id: tx390b2fb557fb4cb48a082-0051923f3b
  Date: Tue, 14 May 2013 13:42:19 GMT

  # Now let's try to disable that tenant
  chmouel@vm:~$ keystone tenant-update --enabled false ${DEMO_TENANT}

  # tenant is disabled all good
  chmouel@vm:~$ keystone tenant-list
  +----------------------------------+--------------------+---------+
  | id | name | enabled |
  +----------------------------------+--------------------+---------+
  | 1f1aeeace0db41e3966a4873877c4dde | admin | True |
  | b39f8b007abe472b93ebb5c7fdd80c98 | demo | False |
  | 64e78275f80d47f998c4cd1f06e79b1e | invisible_to_admin | True |
  | 13fe49ee5e0144d0acd0c89fb9...

Read more...

Dolph Mathews (dolph) wrote :

Malini: yes, that's what these new tests are asserting: https://review.openstack.org/#/c/31564/2/tests/test_v3_auth.py

Thierry Carrez (ttx) on 2013-06-05
information type: Public Security → Public
Thierry Carrez (ttx) wrote :

Triple-checking the need for a public OSSA on this

Is there a way for the admin to disable all tokens already issued for a tenant he wants to disable ? Then I'd tend to consider this a poor feature with potential security consequences (requiring information) rather than a vulnerability.

information type: Public → Public Security
Changed in ossa:
status: New → Incomplete
Dolph Mathews (dolph) wrote :

There's no convenient way to revoke the correct subset of tokens through the API or through the backend itself (even the SQL driver doesn't index by tenant/project). Depending on the actual driver in use, I'd suggest a brute force solution to wipe *all* tokens:

SQL: delete from token;
memcache: Restart memcache
KVS: Restart keystone

Thierry Carrez (ttx) on 2013-06-14
Changed in keystone:
importance: Critical → High
Jeremy Stanley (fungi) wrote :

It's always wise to tread lightly where authentication behavior and the principle of least surprise are concerned. I don't think this warrants an OSSA, but might benefit from an OSSG security note with recommendations for how deployers can work around this shortcoming in production (whether that's clearing all active tokens or something more targeted).

Thierry Carrez (ttx) wrote :

Adding an OSSN task to see if this would be better served by one.

Thierry Carrez (ttx) wrote :

@Rob: would that fall under OSSN ?

Robert Clark (robert-clark) wrote :

Yeah, we can cut an OSSN for this. I'm not a keystone expert though so I'd like some better guidance here before we write the note, who should I reach out to for more info?

Changed in ossn:
importance: Undecided → High
assignee: nobody → Robert Clark (robert-clark)
Thierry Carrez (ttx) on 2013-07-03
no longer affects: ossa
information type: Public Security → Public
Robert Clark (robert-clark) wrote :

Does this get fixed when PKI-Tokens are used more (They seem to either support ephemeral i.e short-life tokens and/or revocation)

Changed in ossn:
assignee: Robert Clark (robert-clark) → Chmouel Boudjnah (chmouel)
Changed in ossn:
assignee: Chmouel Boudjnah (chmouel) → nobody
Changed in keystone:
assignee: Dolph Mathews (dolph) → Chmouel Boudjnah (chmouel)
Changed in ossn:
assignee: nobody → Robert Clark (robert-clark)
Robert Clark (robert-clark) wrote :

[DRAFT]
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

Changed in ossn:
status: New → In Progress
Robert Clark (robert-clark) wrote :

[DRAFT]
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.

NOTE: Flushing memcache can result in loosing token revocation information as addressed in https://bugs.launchpad.net/ossn/+bug/1182920

### 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

Robert Clark (robert-clark) wrote :

[DRAFT]
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.

NOTE: Flushing memcache can result in loosing token revocation information as addressed in https://bugs.launchpad.net/ossn/+bug/1182920

### Contacts / References ###
Proposed Fix : https://review.openstack.org/#/c/39878/
This OSSN : https://bugs.launchpad.net/ossn/+bug/1179955
CVE : CVE-2013-4222
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Bryan D. Payne (bdpayne) wrote :

I suggest removing "It appears that " from the start of the discussion.

Also "Take the case where a cloud provider must a tenant's" should be "Take the case where a cloud provider must revoke a tenant's".

Also " - There are many other abuse-cases..." should be "There are many other abuse-cases."

From ${URL} :

### 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

References:
http://lists.openstack.org/pipermail/openstack-security/2013-August/000263.html

@maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.

Patch is currently under consideration by upstream. Can either apply it now or wait for inclusion in the next release.

I am comfortable taking the patch if it's been committed to master (and preferably to the stable branches).

Reviewed: https://review.openstack.org/39878
Committed: http://github.com/openstack/keystone/commit/74f788aa9da0dabf54bd1f4718f9c0e0b9726757
Submitter: Jenkins
Branch: master

commit 74f788aa9da0dabf54bd1f4718f9c0e0b9726757
Author: Chmouel Boudjnah <email address hidden>
Date: Fri Aug 2 10:12:03 2013 +0200

    Revoke user tokens when disabling/delete a project

    - Revoke tokens scoped to all users from a project when disabling or
      deleting the project.
    - Tests provided by Dolph.

    Closes-Bug: #1179955
    Change-Id: I8ab4713d513b26ced6c37ed026cec9e2df78a5e9
    Signed-off-by: Chmouel Boudjnah <email address hidden>

Changed in keystone:
status: In Progress → Fix Committed

Looks like patch was merged into upstream master. Not certain whether it's been released anywhere.

Robert Clark (robert-clark) wrote :

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 ###
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 revoke 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.

NOTE: Flushing memcache can result in loosing token revocation information as addressed in https://bugs.launchpad.net/ossn/+bug/1182920

### Contacts / References ###
Proposed Fix : https://review.openstack.org/#/c/39878/
This OSSN : https://bugs.launchpad.net/ossn/+bug/1179955
CVE : CVE-2013-4222
OpenStack Security ML : openstack-security at lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Robert Clark (robert-clark) wrote :

Published to OpenStack ML 30/08/2013

Changed in ossn:
status: In Progress → Fix Released
Dolph Mathews (dolph) wrote :

Will likely be addressing during icehouse using a new approach to revocation-
https://blueprints.launchpad.net/keystone/+spec/revocation-events

Rob -- did you issue this OSSN already? If not ..

May need to clarify Memcache without DB backend ( in "If you deploy using Memcache .." ), where flushing cache would resolve the issue. If there is a DB behind it, your next paragraph with DB script necessary to clean up.

And given Chmouel's fix has been committed .. please add

 "Patch https://review.openstack.org/39878 addresses the issue and will be part of the next official release of OpenStack/Keystone. "

Regards
Malini

Dolph Mathews (dolph) wrote :

> Will likely be addressing during icehouse using a new approach to revocation

I should revise my own comment #22 as it's not very clear. What I meant to say was:

> While this has been addressed for havana, we will *likely* be taking a new approach to revocation during icehouse

Thierry Carrez (ttx) on 2013-09-05
Changed in keystone:
milestone: none → havana-3
status: Fix Committed → Fix Released
Matthew Thode (prometheanfire) wrote :

Was this a bug only in havana? or in grizzly/folsom as well?

I'm pretty sure that this is a bug in Havana only so does not effect us. I will let you know when I verify.

Matthew Thode (prometheanfire) wrote :

ttx seems to think this applies to folsom/grizzly, can I get a patch for each please :D

ok, it is a grizzly issue. Also, upstream is 50/50 on whether or not they will backport.

Changed in keystone (Gentoo Linux):
importance: Unknown → Low

fix present in the following versions

via non-upstream-merged patch
keystone-2012.2.4-r9
keystone-2013.1.3-r3
keystone-2013.1.9999

via upstream-merged patch
keystone-9999

no vulnerable stuff in tree, removing myself from cc, feel free to add me if more work is needed.

noglsa. Done here.

Changed in keystone (Gentoo Linux):
status: Unknown → Fix Released

Reviewed: https://review.openstack.org/46371
Committed: http://github.com/openstack/keystone/commit/c70f8c61d50c2358d712b365bec4a8f288314b54
Submitter: Jenkins
Branch: stable/grizzly

commit c70f8c61d50c2358d712b365bec4a8f288314b54
Author: Dolph Mathews <email address hidden>
Date: Thu Sep 12 17:02:26 2013 -0500

    Revoke user tokens when disabling/delete a project

    - Revoke tokens scoped to all users from a project when disabling or
      deleting the project.
    - Fix provided by chmouel

    Closes-Bug: #1179955
    Change-Id: I8ab4713d513b26ced6c37ed026cec9e2df78a5e9

CVE changes are now in stable/grizzly, causing the patch and ebuild to fail.

https://github.com/openstack/keystone/tree/stable/grizzly

 * Failed Patch: 2013.1.3-CVE-2013-4222.patch !
 * ( /usr/portage/sys-auth/keystone/files/2013.1.3-CVE-2013-4222.patch )
 *
 * Include in your bugreport the contents of:
 *
 * /var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/2013.1.3-CVE-2013-4222.patch-2868.out

 * ERROR: sys-auth/keystone-2013.1.9999::gentoo failed (prepare phase):
 * Failed Patch: 2013.1.3-CVE-2013-4222.patch!
 *
 * Call stack:
 * ebuild.sh, line 93: Called src_prepare
 * environment, line 4233: Called distutils-r1_src_prepare
 * environment, line 1157: Called distutils-r1_python_prepare_all
 * environment, line 1076: Called epatch '/usr/portage/sys-auth/keystone/files/2013.1.3-CVE-2013-4222.patch'
 * environment, line 1796: Called die
 * The specific snippet of code:
 * die "Failed Patch: ${patchname}!";
 *
 * If you need support, post the output of `emerge --info '=sys-auth/keystone-2013.1.9999::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-auth/keystone-2013.1.9999::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-auth/keystone-2013.1.9999/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-auth/keystone-2013.1.9999/work/keystone-2013.1.9999'
 * S: '/var/tmp/portage/sys-auth/keystone-2013.1.9999/work/keystone-2013.1.9999'
qemu2 keystone #

CVE-2013-4222 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4222):
  OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and
  Havana before havana-3 does not properly revoke user tokens when a tenant is
  disabled, which allows remote authenticated users to retain access via the
  token.

Reviewed: https://review.openstack.org/46381
Committed: http://github.com/openstack/keystone/commit/7244e5342acb86c241e2d03fc76897174302de04
Submitter: Jenkins
Branch: stable/folsom

commit 7244e5342acb86c241e2d03fc76897174302de04
Author: Dolph Mathews <email address hidden>
Date: Thu Sep 12 17:02:26 2013 -0500

    Revoke user tokens when disabling/delete a tenant

    Revoke tokens scoped to all users from a tenant when disabling or
    deleting the tenant.

    Closes-Bug: #1179955
    Change-Id: I8ab4713d513b26ced6c37ed026cec9e2df78a5e9

Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-3 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.