← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1750415] Re: validation of app cred tokens is dependent on CONF.token.cache_on_issue

 

Reviewed:  https://review.openstack.org/545971
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=796198f19670e3eb899ca3b1db5d2a21a4127a30
Submitter: Zuul
Branch:    master

commit 796198f19670e3eb899ca3b1db5d2a21a4127a30
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Mon Feb 19 18:23:25 2018 +0000

    Populate application credential data in token
    
    Without this patch, the token formatter does not have enough data to
    construct a token created with an application credential. This means
    that if the token cache is disabled or expired, when keystone goes to
    create the token it will not find any application credential information
    and will not recreate the application_credential_restricted parameter in
    the token data. This patch creates a new Payload class for application
    credentials so that the application credential ID is properly persisted
    in the msgpack'd payload. It also adds more data to the token data
    object so that the application credential ID and name as well as its
    restricted status is available when the token is queried.
    
    Co-authored-by: Lance Bragstad <lbragstad@xxxxxxxxx>
    
    Change-Id: I322a40404d8287748fe8c3a8d6dc1256d935d84a
    Closes-bug: #1750415


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

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

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) queens series:
  Triaged
Status in OpenStack Identity (keystone) rocky series:
  Fix Released

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


References