Token providers should be a very simple class to create for anyone looking to develop a custom provider. This opens the door(s) for allowing many token providers both in-tree and out of tree while maintaining the token issuance API contract.
As of today to create a new token provider (with a new ID format), it requires a lot of knowledge of how Keystone handles token issuance and what all the raw data should look like. Keystone should have a very simple and easy to understand interface for token providers. This allows new token-id formats to be easily created that can/will meet specific deployer needs.
Keystone’s token providers should be loaded with stevedore and have an extremely stable API. This API should be very stable (enforced as a stable contract in the same manner we enforce the REST API contract).
The new interface should be:
Issue Token: A method that accepts a clear data model (similar to the current token data model introduced in Juno) and allows for extracting the data in a way that can be used to generate a Token ID. The most extreme case of this would be the PKI token where all of the data is encoded into the ID itself.
The issue token method would also make decisions such as persisting the token data to some sort of stable storage and/or pre-seeding caches.
A Token-ID type will need to be encoded into the Token ID (for new token types) allowing Keystone and Middleware to load the correct provider(s) to handle validating the token. Longer term this allows us to support multiple ID types (seamless conversion).
Validate Token: A method that performs the validation and either utilizes Keystone’s managers/etc to regenerate the token data or to extract the data directly (in the case of something akin to the PKI token model).
Validate Token will be responsible for running the data through the token data formatter if needed.
Middleware Plugin: A class that can be utilized by Keystone middleware to validate the token. A default behavior will be to utilize the UUID model where middleware performs an HTTP request to Keystone to validate the token and receive the token data / body back. Likely most providers will not re- implement this. An example provider that will re-implement this will be the PKI token provider.
Middleware Plugin will use a method in common with Validate Token to avoid retrieving the token data from the persisted store more than once.
The V2 and V3 token helper classes will be refactored to take the token model and emit the documented token data format. The token data formats will be documented for developers and formatter classes for each version will be provided (currently V2 and V3).
Any changes to this API will either need to be 100% compatible (no way to cause an exception to be raised) or require an Adapter class to handle older provider interfaces.
None. This is a change of design, the alternative is to maintain the same design we have today.
This change does affect tokens and potentially could have a security impact, however, the goal is to maintain the same functionality but refactor the way in which Keystone manages token issuance and token validation.
The new token provider(s) will need to be evaluated for security.
There will be no notification impact. Notifications will be handled outside of the provider Issue Token method ensuring the new providers do not need to be aware of notification/cadf logic.
Deployers will be able to develop their own token-id formats and validation. This means token IDs may change what they look like. These changes should be transparent to the end-user.
Performance should have no direct impact from this change. This will, however, allow deployers to select the best token provider for their deployments.
Deployers will be able to choose the best token provider for their deployment. Future development will allow for multiple providers (validation) so that changing from one provider to another should be seamless to the end-user.
Developers will have a very strictly contracted API to develop providers against. This should improve developer experience significantly.
Morgan Fainberg <mdrnstm>
No extra dependencies.
No external references.