keystonemiddleware without TRL checking and default cache config can allow access after token revocation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
Fix Released
|
Undecided
|
Doug Chivers | ||
keystonemiddleware |
Won't Fix
|
Low
|
Unassigned |
Bug Description
*** This can probably be made public right away, but I am erring on the side of caution and letting the VMT make this call ***
Yukihiro KAWADA reported an issue with Keystone that indirectly led/confirmed an issue with Keystonemiddleware when the Token Revocation List (TRL) is not utilized and caching is enabled (default). If the TRL is not used (common with UUID tokens, as PKI signing is not setup), a token that is used on an endpoint is valid for 300s (default, may be more/less based on config) even if the token is revoked within keystone (this include disabling of the user).
Worse, the default is is to cache the tokens in-process memory, which means that the token may appear to be revoked/invalid in some cases and then become re-valid on subsequent requests unless a shared cache is used.
This appears to be insane default(s) that lead to a window of exposure that is not clearly communicated either with defaults or when caching times are adjusted.
Changed in ossn: | |
assignee: | nobody → Dave Walker (davewalker) |
Changed in ossn: | |
status: | New → In Progress |
assignee: | Dave Walker (davewalker) → Doug Chivers (doug-chivers) |
Changed in keystonemiddleware: | |
status: | New → Triaged |
importance: | Undecided → Low |
This bug was split from https:/ /bugs.launchpad .net/keystone/ +bug/1434034