Use Clock for Revoked tokens
The memcache and other KVS backends have very awkward "list tokens for user" semantics. Expired and revoked tokens are collecting in "index" records.
A cleaner appraoch is for each uyser to have a "clock" for their tokens.
the clock starts a 0. A valid token has a clock value equal to that of the users clock.
When an event happens that should revoke a users token, the users clock is advanced. Checking token validation then is a matter of looking up the users clock value and comparing with the tokens clock value.
For revocation lists, we will maintain a list of users that have tokens that have been revoked but that would not have expired. The auth_token middleware will fetch this list and use it to check the validity of the tokens it verifies inline.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Adam Young
- Direction:
- Needs approval
- Assignee:
- Morgan Fainberg
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Morgan Fainberg
Related branches
Related bugs
Sprints
Whiteboard
Not certain we can make this work. This makes all token revocation events affect all tokens in the system for a given user. This is fairly draconian, and will negatively impact user experience where, for example, the deletion of a project that a user is in will invalidate tokens in active use. A malicious project admin could prevent a user from doing any real work by repeated adding and removing them from a group.
In response to the malicious project admin:
This issue (the draconian revocation) already exists in the current implementation.
There could be a two-fold approach to this problem. The first part of the solution is to use a KRB5-ism and really enforce the concept of an "identity" token vs a "permission" token (effectively use a Token-granting-
Another thought would be (in lieu of the clock per domain) to give a grace period on the clock, so that coupled with a TGT a given permission token in guaranteed a minimal life-span so that an action can be taken without a rapid clock increment preventing all actions. If the interface properly handles token-granting via the TGT (and re-issuing if revoked) it would mitigate the malicious project admin scenario without exposing a large window where a grant wouldn't get refreshed based upon a legitimate change.
If the TGT is revoked all tokens associated to it would be revoked and new authentication would be required.
ayoung:
Tokens out of the reach of the maliciosu admin are not effected. See earlier bugs on token revocation. However, this is just an example of why we don't want to revoke all tokens together.
I think instead we will use Kerberos or X509 itself, and just use the tokens to carry the authentication information. No need to reinvent the wheel.
The grace period obviates the benefit of token revocation.
morganfainberg:
I missed the fixes regarding the bugs. I see them now. If we go with Kerberos or X509, it definitely solves the issue. As long as we maintain usability and keep keystone responsive (i'm not familiar with the overhead full X509 or Kerberos would add) I think we're on the right path in general.
Does it make sense to hit this for Havana? Is this BP increasing scope significantly?
