yahoo-eng-team team mailing list archive

[OpenStack Infra <1778945@xxxxxxxxxxxxxxxxxx>]

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 <lbragstad@xxxxxxxxx>
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