yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #72666
[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