Difference between revisions of "PKI-Revoke"
| Line 1: | Line 1: | ||
= Changes to support revocation of PKI tokens = | = Changes to support revocation of PKI tokens = | ||
| + | |||
| + | (blueprint: https://blueprints.launchpad.net/keystone/+spec/pki-revoke) | ||
| + | |||
| Line 5: | Line 8: | ||
# Revoked tokens must be recorded, not merely removed from the tokens backend. To effect this there are two choices: | # Revoked tokens must be recorded, not merely removed from the tokens backend. To effect this there are two choices: | ||
## 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() | ## 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() | ||
| − | ## 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. | + | ## 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() |
| − | # Either way, at token timeout, the tokens will be removed from the table. | + | # Either way, at token timeout, the tokens will be removed from the relevant table. |
# Once revoked, a token cannot be unrevoked. | # Once revoked, a token cannot be unrevoked. | ||
| Line 12: | Line 15: | ||
# The Keystone server will expose a list of revoked tokens exposed in an URL. | # The Keystone server will expose a list of revoked tokens exposed in an URL. | ||
## GET /tokens/revoked/ | ## GET /tokens/revoked/ | ||
| − | # 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 | + | # 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) |
# The revocation list will be a signed CMS document | # The revocation list will be a signed CMS document | ||
# The body of the revocation list will be the id_hash values of the tokens. | # 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 == | == Changes to auth_token middleware == | ||
# Services runnning auth_token middleware will query the Revocation list on a simple schedule. | # Services runnning auth_token middleware will query the Revocation list on a simple schedule. | ||
| + | |||
| + | (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? | ||
| + | |||
# The time out will be a configuration option. | # The time out will be a configuration option. | ||
| + | |||
| + | (heckj) time out to requesting a revised set of revoked tokens from the Keystone service? | ||
| + | |||
# 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. | # 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. | ||
# If the Keystone server cannot be reached, authentication will fail | # If the Keystone server cannot be reached, authentication will fail | ||
| Line 24: | Line 35: | ||
== Future enhancements == | == Future enhancements == | ||
# wait a random amount of time and then requery the Keystone server. | # wait a random amount of time and then requery the Keystone server. | ||
| − | # Support | + | # Support a set of Keystone servers where the policy for revocation checking can vary per server. |
| − | # Support a setup where a subset of the Keystone | + | # 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. |
Revision as of 16:10, 7 August 2012
Contents
Changes to support revocation of PKI tokens
(blueprint: https://blueprints.launchpad.net/keystone/+spec/pki-revoke)
Changes to the current token invalidation process
- Revoked tokens must be recorded, not merely removed from the tokens backend. To effect this there are two choices:
- 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()
- 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()
- Either way, at token timeout, the tokens will be removed from the relevant table.
- Once revoked, a token cannot be unrevoked.
Change to the Keystone API
- The Keystone server will expose a list of revoked tokens exposed in an URL.
- GET /tokens/revoked/
- 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)
- The revocation list will be a signed CMS document
- 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
- Services runnning auth_token middleware will query the Revocation list on a simple schedule.
(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?
- The time out will be a configuration option.
(heckj) time out to requesting a revised set of revoked tokens from the Keystone service?
- 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.
- If the Keystone server cannot be reached, authentication will fail
Future enhancements
- wait a random amount of time and then requery the Keystone server.
- Support a set of Keystone servers where the policy for revocation checking can vary per server.
- 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.
