Latest revision as of 07:01, 22 September 2013

Old Design Page This page was used to help design a feature that has been implemented. As a result, this page is unlikely to be updated and could contain outdated information. It was last updated on 2013-09-22

Changes to support revocation of PKI tokens

(blueprint: https://blueprints.launchpad.net/keystone/+spec/pki-revoke)

Changes to the current token invalidation process

1. Revoked tokens must be recorded, not merely removed from the tokens backend. To effect this there are two choices:
   1. SQL Backend: Add an additional column in the database: revoked. Change the authenticate code to check for revoked status. Attemptes to authenticate using a revoked token will raise exception.Unauthorized()
   2. KVS Backend: Create an additional variable in the backend: revoked_tokens. Revoked tokens will be removed from self.db.items(): just as they are now, and added to the revoked_tokens collection.
   3. memcached Backend: A single memcached item with key "revoked_tokens" will contain a list of all revoked tokens. Revoked tokens will be removed from their individual memcached items, and added to the revoked_tokens item. This will be done in a thread safe manner with "last write wins" semantics.
   4. For all cases, the information recorded will be the hash of the PKI token and the token expiry.
2. At token timeout, revoked tokens will be removed from the backend
3. Once revoked, a token cannot be unrevoked.

Change to the Keystone API

1. The Keystone server will expose a list of revoked tokens exposed in an URL.
   1. GET /tokens/revoked/
2. Only exposed on the admin port. This is to prevent a race condition attack where a user finds out about a revoked token and attempts to use it before the servicesare ware it has been revoked (or wrapped in RBAC so that only services with an appropriate role can use the API)
3. The revocation list will be a signed CMS document
4. The body of the revocation list will be the id_hash values of the tokens.

(heckj): thought here being to have the services periodically check this URL and get an updated list of revoked tokens? Are we expecting services (nova, glance, swift, quantum, etc) to need to do this periodically as a means of pre-caching a list of revoked tokens (so they can pre-emptively know that a token has been revoked and not make the call back to Keystone)?

Changes to auth_token middleware

(Revised to answer the questions by heckj: this is middleware - not something that typically operates on a schedule. What kind of means of periodic update did you think we could use here? Time out to requesting a revised set of revoked tokens from the Keystone service)

1. When the middleware receives an authentication request, it will check to see if the token provided is on a cached version of the token revocation list.
2. If the token revocation list is not present or is out of date, the auth_token middleware will request an updated revocation list.
3. Only one request to the Keystone server will be active at any given time. If multiple token requests come in at once, they will all block until the revocation list request returns
4. The cache invalidation time out will be a configuration option.
5. If the middleware request cannot reach the Keystone server, authentication will fail

Future enhancements

1. wait a random amount of time and then requery the Keystone server.
2. Support a set of Keystone servers where the policy for revocation checking can vary per server.
3. Support a setup where a subset of the Keystone servers are not be directly accessible. In those cases, one Keystone server can proxy the revocation list for another server.