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

[Morgan Fainberg]

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

[Morgan Fainberg (mdrnstm)]

This bug was split from https://bugs.launchpad.net/keystone/+bug/1434034

[Brant Knudson (blk-u)]

duplicate of https://bugs.launchpad.net/python-keystoneclient/+bug/1287301 , IMO.

[Grant Murphy (gmurphy)]

I agree it looks like it could be dup.

Anyway I still added the OSSA task to this bug and marked it incomplete pending a discussion with VMT on how to handle.

I couldn't find where the OSSG published a OSSN for bug 1287301 so it might be worth doing this time around if it was missed last time.

[Thierry Carrez (ttx)]

If I understand correctly the worse case scenario here is a slightly deferred token invalidation, which I would not consider OSSA (advisory) material (could be considered "working as designed"). It is certainly OSSN (security note / documentation) material though.

Given the impact and in order to facilitate work on this, I propose we open this bug publicly.

[Morgan Fainberg (mdrnstm)]

100% spot on Thierry. And I agree we open this to the public. I deferred that choice to the VMT though.

[Tristan Cacqueray (tristan-cacqueray)]

Brant, bug 1287301 affects keystone setups with a TRL while this one affects setups without TRL... Though the behavior is basically the same.

+1 to open this and remove the OSSA task.

[Thierry Carrez (ttx)]

OK, it's public now.

[Dolph Mathews (dolph)]

This is by design, but we have a chance to improve the behavior with token revocation events.

[Morgan Fainberg (mdrnstm)]

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.

[Robert Clark (robert-clark)]

I agree that an OSSN would be appropriate.

[Shellee Aragon (shellee-aragon)]

Review link: https://review.openstack.org/#/c/219922/

[Nathan Kinder (nkinder)]

This has been published as OSSN-0056:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0056

[Morgan Fainberg (mdrnstm)]

This is relatively by design. See previous comments.