Reviewed: https://review.openstack.org/577567 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=140a34b439d9aa60712a164b21622e721a60dfc2 Submitter: Zuul Branch: master
commit 140a34b439d9aa60712a164b21622e721a60dfc2 Author: Lance Bragstad <[email protected]> Date: Fri Jun 22 22:02:04 2018 +0000 Remove KeystoneToken object This commit removes the original KeystoneToken object in favor of the new TokenModel object. Since we have a token provider that knows how to deal with TokenModel object, we don't really need another object that uses reflection at all. Closes-Bug: 1778945 Change-Id: I778cab0a6449184ecf7d5ccfbfa12791be139236 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1778945 Title: Complexity in token provider APIs Status in OpenStack Identity (keystone): Fix Released Bug description: The authentication APIs of keystone (GET|HEAD|POST|DELETE /v3/auth/tokens) leverage the token provider API to deal with token operations. This has traditionally been one of the most complicated areas of keystone for multiple reasons. First, tokens are represented in different ways depending on how the user authenticates, making it non-trivial to build accurate representations of tokens. Second, in the past keystone supported different token providers and different token storage systems which were eventually decoupled. This increased the various paths through the token provider code, complicating the business logic. Third, original implementation of the token provider interface relied on a storage mechanism to hold the entire token reference. This meant that the pluggable token provider needed to understand the complex data structure that is a token response. This was traditionally passed into token provider via the token provider interface as something like ``token_data`` or ``token_ref``. The dictionary was essentially what would be passed to the user over the API, but responsibility of that reference would get passed to pluggable parts of keystone. This meant that it was possible to introduce breaking API changes by using different token providers. This also made it hard for people to implement token providers because they need to understand the intricacies of keystone authentication API just to implement a new token format. These are but a few of the reasons why the token provider API has become increasingly complex and fragile over time. We can improve the situation for maintainers and external developers providing their own token providers by doing a couple things. First, we can consolidate all token logic into a token object that is responsible for maintaining the business logic for tokens. Second, we can transition parts of keystone to use this new object instead of actual dictionaries that represent token API responses. Third, we can introduce a method that converts a token model to a token response, and keep that in a single place close to the edge of the authentication API. This will force us to use the object representation within keystone and be explicit in what we give to users, as opposed to opening ourselves up to breaking APIs by passing token references across interfaces outside of our control. Finally, we can redefine the token provider APIs to be extremely explicit since following the above steps will result in less responsibility for people implementing token provider APIs since keystone is handling in. A redefined interface will allow us to add and remove token providers faster and easier. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1778945/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
