yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan.fainberg@xxxxxxxxx>]

Based upon research and discussions in IRC, turns out we do not store
the application_credential_id in the token payload. This means that if
the token is not pre-populated in the cache, the test will fail.

This also means that if the token cache expires, subsequent uses of the
token with the application cred will also fail / have inconsistent or
inappropriate behavior.

This requires a fix to add a formatter that includes
application_credentials (likely more than one). The issue is identified
by looking at
https://github.com/openstack/keystone/blob/c80df22669ae457f8a64ddef7d31f685f9ad1e01/keystone/token/token_formatters.py
and seeing that application credential is not stored anywhere but the
auth methods are properly populated.

** Also affects: keystone/rocky
   Importance: Critical
     Assignee: Lance Bragstad (lbragstad)
       Status: In Progress

** Also affects: keystone/queens
   Importance: Undecided
       Status: New

** Changed in: keystone/queens
   Importance: Undecided => Critical

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

** Changed in: keystone/queens
     Assignee: (unassigned) => Lance Bragstad (lbragstad)

-- 
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/1750415

Title:
  validation of app cred tokens is dependent on
  CONF.token.cache_on_issue

Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack Identity (keystone) queens series:
  Triaged
Status in OpenStack Identity (keystone) rocky series:
  In Progress

Bug description:
  Some information in tokens obtained with application credentials isn't
  available unless caching is enabled. I was able to recreate this using
  some of the tests in test_v3_trust.py and by setting
  CONF.token.cache_on_issue to False, which resulted in a 500 because a
  specific key in the token reference wasn't available [0].

  Without digging into a bunch, I think this is because the token is
  cached when it is created, meaning the process to rebuild the entire
  authorization context at validation time is short-circuited.

  [0] http://paste.openstack.org/show/677666/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750415/+subscriptions