← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1760205] Re: Deleting a shadow user doesn't invalidate the cache

 

Reviewed:  https://review.openstack.org/561908
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=3b701cdf70d7331c781a6b1a46dd8247906b9b63
Submitter: Zuul
Branch:    master

commit 3b701cdf70d7331c781a6b1a46dd8247906b9b63
Author: wangxiyuan <wangxiyuan@xxxxxxxxxx>
Date:   Tue Apr 17 19:21:43 2018 +0800

    Invalidate the shadow user cache when deleting a user
    
    When deleting a user, the cache for the related shadow user should
    be invalidated as well. Otherwise the federation authentication
    will not work well and will raise 404 UserNotFound error.
    
    This patch fixes the bug and adds a new function for shadow backend
    to get the shadow user information.
    
    Change-Id: I3882f0dc6e8f8f618bb89ebd699736bc4b352261
    Closes-bug: #1760205


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

Title:
  Deleting a shadow user doesn't invalidate the cache

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  When you delete a shadow user and the user tries to log in again
  through federation, they'll get a can't find user error. Retrying
  after 10 (or so) minutes works.

  My Setup
  --------
  1. devstack-idp is the identity provider for service provider devstack-sp1, using Keystone to Keystone (SAML) with Shibboleth
  2. user-idp gets a SAML assertion from devstack-idp keystone and uses that to authenticate with devstack-sp1 keystone.
  3. devstack-sp1 create shadow user user-sp1.
  4. admin deletes user-sp1 in devstack-sp1.
  5. Step two is performed again
  6. user-idp gets a 'Could not find user <user-sp1_id>' from devstack-sp1.
  7. After 10 (or so) minutes user tries again, this time it works and he is able to authenticate to <user-sp1> (id of this user-sp1 is different than the prior one).

  Expected: After deleting a shadow user, the user should be able to re-
  authenticate immediately and have a new shadow user created.

  Actual: After deleting a shadow user, the user can't log back into
  keystone if keystone is caching identity information (which is does by
  default). The user can re-authenticate only if the cache is disabled
  or the entry TTL has expired.

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


References