Open Stack

This is a case where an OSSN and eliminating awful defaults will make
behavior less bad. The fact that a similar issue in the past did not
have an OSSN was the main reason this was raised as it was.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1435530

Title:
  keystonemiddleware without TRL checking and default cache config can
  allow access after token revocation

Status in OpenStack Identity  (Keystone) Middleware:
  New
Status in OpenStack Security Advisories:
  Won't Fix
Status in OpenStack Security Notes:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystonemiddleware/+bug/1435530/+subscriptions