PKI-Revoke

Changes to support revocation of PKI tokens

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.
   2. Change the authenticate code to check for revoked status. Attemptes to authenticate using a revoked token will raise exception.Unauthorized()
   3. 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.
   4. Either way, at token timeout, the tokens will be removed from the table.
   5. Once revoked, a token cannot be unrevoked.
2. 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.
   3. This is to prevent a race condition attack where a user finds out about a revoked token and attempts to use it before the services
3. Services runnning auth_token middleware will query the Revocation list on a simple schedule.
   1. The time out will be a configuration option.
   2. The revocation list be a signed CMS document
   3. The body of the revocation list will be the id_hash values of the tokens.
   4. 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.
   5. If the Keystone server cannot be reached, authentication will fail.
4. 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.