Unscoped tokens are revoked when assigning a role to a user

Bug #1170186 reported by Philip Mark M. Deazeta on 2013-04-18
74
This bug affects 13 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
High
Lin Hua Cheng
OpenStack Identity (keystone)
High
Dolph Mathews
Grizzly
High
Dirk Mueller

Bug Description

Back in Folsom, when a user creates a project and add himself onto that project, only the scoped token gets revoked and then we reuse the unscoped token to reauthenticate so that the user won't be logged out of the system.

In grizzly, adding a user to a project would result to all his tokens being revoked even the unscoped ones. I've also tried Keystone V3 hoping that token scoping on domains would solve my problem but still the same thing happens

My test:
Token: UUID
I've created a bunch of tokens with different scopes, some scoped to domain and some with projects

mysql> SELECT id, valid FROM token WHERE user_id = "b68e401ce94c4aefbe1b1699e5a62956" AND valid = 1;
+---------------------------------------------------------+-------+
| id                               | valid |
+---------------------------------------------------------+-------+
| 067bb96c5ee3491c916c4db73693dfff |     1 | ----> Unscoped token
| 3ba0ee57018c400f925d680068eb797e |     1 | ----> Scoped token
| cdb6fe2a1d23477f8bb4339afc7ae2ec |     1 |----> Unscoped token
| e0f66872d37b4c8bab41e63a35313867 |     1 | ----> Scoped Token
+---------------------------------------------------------+-------+

--------> Then I added that user to a project

mysql> SELECT id, valid FROM token WHERE user_id = "b68e401ce94c4aefbe1b1699e5a62956" AND valid = 1;
Empty set (0.00 sec)

--------> All tokens no matter what scope became invalid

This also relates to the bugs filed in Horizon

https://bugs.launchpad.net/horizon/+bug/1060426
https://bugs.launchpad.net/horizon/+bug/1166794

description: updated
description: updated
description: updated

diff --git a/keystone/identity/controllers.py b/keystone/identity/controllers.py
index e82b81f..7676195 100644
--- a/keystone/identity/controllers.py
+++ b/keystone/identity/controllers.py
@@ -299,7 +299,7 @@ class Role(controller.V2Controller):

         self.identity_api.add_role_to_user_and_project(
             context, user_id, tenant_id, role_id)
- self._delete_tokens_for_user(context, user_id)
+ self._delete_tokens_for_user(context, user_id, tenant_id)

         role_ref = self.identity_api.get_role(context, role_id)
         return {'role': role_ref}

xingzhou (xingzhou) wrote :

is there any reason for why the tokens, including scoped token, shall be revoked when addinguser to a tenant? For removing users from roles or tenant, seems the revoke of token can help delete the invalid tokens.

Gabriel Hurley (gabriel-hurley) wrote :

I ran into this testing things with the v3 API and it's exceedingly annoying. This is a breaking change in the Keystone API behavior and we should discuss what makes the most sense here. Becoming immediately unauthorized when taking this action causes various other problems in Horizon where multiple API requests may be queued together.

Changed in horizon:
importance: Undecided → High
milestone: none → havana-1
status: New → Confirmed
Changed in horizon:
milestone: havana-1 → havana-2
Lin Hua Cheng (lin-hua-cheng) wrote :

The token also gets expired when the owner is added or removed from a group.

+1 on exceedingly annoying.

tags: added: grizzly-backport-potential
Dolph Mathews (dolph) wrote :

Revoking tokens as a result of a role assignment was simply overkill. I don't think we need to revoke any tokens, and we can instead place the burden on the user to figure out that they should re-authenticate to take advantage of recent role assignments.

Changed in keystone:
importance: Undecided → High
status: New → Triaged
status: Triaged → Confirmed

I think that the best option here is at least show a message (in Horizon) indicating a re-authentication needed, avoiding the annoying errors. Also, is important to restrict the rol changes of the user logged to only one, and doesn't permit more than it.

Dolph Mathews (dolph) wrote :

> Also, is important to restrict the rol changes of the user logged to only one, and doesn't permit more than it.

How/why?

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

Changed in keystone:
assignee: nobody → Dolph Mathews (dolph)
status: Confirmed → In Progress

Reviewed: https://review.openstack.org/31548
Committed: http://github.com/openstack/keystone/commit/132ff6d85e02acdce7483c2848686676cb4f14a0
Submitter: Jenkins
Branch: master

commit 132ff6d85e02acdce7483c2848686676cb4f14a0
Author: Dolph Mathews <email address hidden>
Date: Mon Jun 3 14:21:36 2013 -0500

    Maintain tokens after role assignments (bug 1170186)

    Change-Id: Iacd2d9e09be4ab3d6a3c5acf4074e4af7e300602

Changed in keystone:
status: In Progress → Fix Committed
Changed in horizon:
assignee: nobody → Lin Hua Cheng (lin-hua-cheng)

Dolph: The patch https://review.openstack.org/31548 only took care of creation of role assignment to user. The token is also revoked on removal of role assignment from user, add/remove user from group. Should we also remove token revocation for those operations?

Dolph Mathews (dolph) wrote :

Lin Hua Cheng: Yes, I agree. I've opened bug 1187359 to track that work.

summary: - Unscope token gets revoked when adding a user to a project
+ Unscoped tokens are revoked when assigning a role to a user
Lin Hua Cheng (lin-hua-cheng) wrote :

Validated that assigning roles to User/Group does not revoke the token anymore, this was fixed in Keystone.

Revoking roles from User/Group still revokes the token.

For revoking roles from User/Group, it is by design to revoke the token immediately because from security perspective revoking roles must be immediate to prevent user from further accessing the system. Adding roles is less important and could wait until the user re-authenticates.

Changed in horizon:
status: Confirmed → Fix Committed
Thierry Carrez (ttx) on 2013-07-17
Changed in horizon:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-07-17
Changed in keystone:
milestone: none → havana-2
status: Fix Committed → Fix Released
Alan Pevec (apevec) wrote :

cherry pick with original change-id https://review.openstack.org/40249

Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-2 → 2013.2
Thierry Carrez (ttx) on 2013-10-17
Changed in horizon:
milestone: havana-2 → 2013.2
Alan Pevec (apevec) on 2014-03-30
tags: removed: grizzly-backport-potential
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions