[Openstack-security] [Bug 1287301] Re: Keystone client token cache doesn't respect revoked tokens

Matthew Edmonds edmondsw at us.ibm.com
Wed Mar 12 12:11:20 UTC 2014


caching tokens for 5 minutes by default may be all well and good for performance, but not so much for security. Consider the following cases:
1) If an admin detects that someone is using a token maliciously, they'll delete it and expect that to stop the usage immediately. But it won't.
2) If someone deletes the token they were using and then walks away, they should not have to worry about someone else stepping up and continuing to use that token.

Is token caching really something we should be doing at all? By default?

If so, should the default really be as high as 5 minutes? How did we
settle on such a large value?

Should we implement a notification mechanism for token revokation which
would cause listening clients to update their cache immediately? (Note:
someone may find a way to block the notification, so this isn't
perfect...)

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

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




More information about the Openstack-security mailing list