Persistent tokens are not cleaned up when removing users from projects

Bug #1700748 reported by zhengliuyang on 2017-06-27
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Low
zhengliuyang

Bug Description

If deleting a role, we should iterate over the assignments for this role and build the list of tokens we need to delete. In order to minimize the number of token list to delete, remove any redundant user+project deletions.

I think simplify the list for the same user is Improper, the same user and different project target different tokens. At the same time, original processing actually doesn't work due to user_ids is never added to.

Changed in keystone:
assignee: nobody → zhengliuyang (zlyqqq)
status: New → In Progress
Lance Bragstad (lbragstad) wrote :

I'm not sure which specific issue this report is highlighting. Is it a question of validating a token after a role has been deleted?

 - a user get role x on project y
 - a user gets a token scoped to project y
 - role x is deleted
 - a user attempts to validate the project scoped token

The last step in that flow should return a 401 since the user won't have a role on the project. Also, since the fernet token format is non-persistent, keystone isn't able to generate a list of tokens based on the role in the token.

Can you provide links to the code that you think needs to be improved?

Changed in keystone:
status: In Progress → Invalid
Changed in keystone:
status: Invalid → In Progress
summary: - Improper handle building list of token deletion
+ Persistent tokens are not cleaned up when removing users from projects
Lance Bragstad (lbragstad) wrote :

I was able to recreate this by doing the following:

- switch to using the uuid token provider
- as an admin, create a user and assign them a role on a project
- generate some tokens using the new user
- confirm that the tokens exist in the backend
- as an admin, remove the user from the project
- attempt to validate the users token (should result in a 404)
- confirm the invalidated tokens are still in the backend

The tokens are considered invalid because we rely on token validation to rebuild the users assignments for the token. If the user doesn't have any valid role assignments on the project in question, the token is considered invalid.

If there is an issue with this flow it's that keystone leaves invalid tokens in the backend (which causes bloat). From an API perspective, things are working as designed. This is limited to only token providers that require persistent storage, so UUID.

Changed in keystone:
importance: Undecided → Low
Lance Bragstad (lbragstad) wrote :

Now that we're in the Rocky development cycle, we've removed the uuid token provider and the sql token storage driver, since it was slated for removal this release [0].

[0] https://review.openstack.org/#/c/543060/

Changed in keystone:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers