Public bug reported: ## Problem Currently, changes to group assignments in Keycloak are not immediately reflected during the user login process in Keystone. For example:
- When a user is assigned to Group A in Keycloak, they are unable to access the projects where Group A has role assignments until after a 10-minute delay. - Similarly, if a user is removed from Group A, they can still access projects where Group A has role assignments for up to 10 minutes after the removal. ## Root Cause After troubleshooting, it was discovered that this issue stems from Keystone's core assignment implementation. Specifically, in the following commit: https://opendev.org/openstack/keystone/commit/63124f703a81074793360c1b91711b6ee5a76196 The `list_projects_for_user` function in Keystone leverages `oslo.cache`. This cache is invalidated when any role assignment is added or removed within Keystone itself. In keycloak federation, since group assignment changes occur within Keycloak and not Keystone, these operations fall outside Keystone's direct control, and thus the cache is not invalidated when group assignments are changed in Keycloak. As a result, users must wait for the cache to expire (configured as `cache.expiration_time` https://docs.openstack.org/keystone/latest/configuration/config- options.html#cache.expiration_time in Keystone’s configuration, typically 10 minutes) before changes in group assignments are reflected in OpenStack. ## Scope This issue exists in not only Keycloak backend but also other authentication backends such as LDAP. ## Proposed solution This delay in reflecting group assignment changes is due to Keystone caching the list of projects and domains for users, and the fact that group assignment operations in Keycloak are not within Keystone's scope. To address this issue, either the caching mechanism needs adjustment, or a mechanism for invalidating the cache when group assignments change in Keycloak needs to be implemented. ** Affects: keystone Importance: Undecided Status: New -- 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/2083004 Title: Group/Role Assignment Changes in Keycloak Not Reflected Immediately in Keystone Authentication Status in OpenStack Identity (keystone): New Bug description: ## Problem Currently, changes to group assignments in Keycloak are not immediately reflected during the user login process in Keystone. For example: - When a user is assigned to Group A in Keycloak, they are unable to access the projects where Group A has role assignments until after a 10-minute delay. - Similarly, if a user is removed from Group A, they can still access projects where Group A has role assignments for up to 10 minutes after the removal. ## Root Cause After troubleshooting, it was discovered that this issue stems from Keystone's core assignment implementation. Specifically, in the following commit: https://opendev.org/openstack/keystone/commit/63124f703a81074793360c1b91711b6ee5a76196 The `list_projects_for_user` function in Keystone leverages `oslo.cache`. This cache is invalidated when any role assignment is added or removed within Keystone itself. In keycloak federation, since group assignment changes occur within Keycloak and not Keystone, these operations fall outside Keystone's direct control, and thus the cache is not invalidated when group assignments are changed in Keycloak. As a result, users must wait for the cache to expire (configured as `cache.expiration_time` https://docs.openstack.org/keystone/latest/configuration/config- options.html#cache.expiration_time in Keystone’s configuration, typically 10 minutes) before changes in group assignments are reflected in OpenStack. ## Scope This issue exists in not only Keycloak backend but also other authentication backends such as LDAP. ## Proposed solution This delay in reflecting group assignment changes is due to Keystone caching the list of projects and domains for users, and the fact that group assignment operations in Keycloak are not within Keystone's scope. To address this issue, either the caching mechanism needs adjustment, or a mechanism for invalidating the cache when group assignments change in Keycloak needs to be implemented. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/2083004/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
