Revision as of 17:00, 7 August 2012

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. 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. Create an additional table: revoked_tokens. Revoked tokens will be removed from the tokens table just as they are now, and added to the revoked_tokens table. Change "authenticate" code to check for revoked status, and attempts to authenticate using a revoked token will raise exception.Unauthorized()
2. Either way, at token timeout, the tokens will be removed from the relevant table.
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.