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.

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?

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