yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

Public bug reported:

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.

** Affects: keystone
     Importance: Medium
         Status: Triaged

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
       Status: New => Triaged

-- 
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):
  Triaged

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