Revision as of 13:55, 7 August 2012

Changes to support revocation of PKI tokens

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.
2. Either way, at token timeout, the tokens will be removed from the 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
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.

Changes to auth_token middleware

1. Services runnning auth_token middleware will query the Revocation list on a simple schedule.
2. The time out will be a configuration option.
3. If a token authentication request comes in to the auth_token middle and the service does not have a recent revocation list, it is fetched from keystone.
4. If the Keystone server cannot be reached, authentication will fail

Future enhancements

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