Open Stack

d-w-chadwick , robert-clark : Based on the fix in
https://review.openstack.org/#/c/78241/ , it looks like if the token is
validated once and put in the cache, then after that the token is valid
for the entire cache period (token_cache_time, which defaults to 5 mins)
even if the token is revoked.

With PKI tokens, we've now got the revocation list... should auth_token
be checking the revocation list for both UUID and PKI tokens?

With the latest change to set the revocation_cache_time to 5 minutes,
then if a deployment is using the defaults there's nothing to gain by
checking the revocation list... it'll be just as out of date as the
cache. If someone was willing to set a lower time for
revocation_cache_time then they'd have the shorter valid period for
tokens.

What I'm trying to figure out is -- if we take the fix in
https://review.openstack.org/#/c/78241/ will that provide more
flexibility for the deployer to pick how they want revocations to work
with caching? They can set revocation_cache_time to 10 seconds and
tokens will be valid for 10 seconds after they're revoked... but they
can already do the same thing by setting a short cache time, and then
the code would be using the normal flow for UUID tokens which validates
them against keystone rather than getting the revocation list.

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

Title:
  Keystone client token cache doesn't respect revoked tokens

Status in OpenStack Security Advisories:
  Invalid
Status in Python client library for Keystone:
  In Progress

Bug description:
  If we'll enable caching for keystoneclient tokens we'll be able to use
  tokens that are already revoked if they are present in cache:

  https://github.com/openstack/python-
  keystoneclient/blob/0.6.0/keystoneclient/middleware/auth_token.py#L831

  steps to recreate:
  1) get a token
  2) use it to make a request via keystoneclient using default properties (thus it will be cached)
  3) delete the token
  4) use the token to make another request via keystoneclient

  expected result: the token should not work (HTTP 401)
  actual result: the token still works

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