-
Notifications
You must be signed in to change notification settings - Fork 5
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.
Current authentication Flow
When a user logs into Horizon (OpenStack Dashboard), they are redirected to the Keycloak login page. Upon successful authentication in Keycloak, an access token is generated and redirected to Keystone’s websso URL. Keystone validates this token, and the user’s authentication is confirmed.
The next step is authorization. Keystone checks the user's role assignments by retrieving the list of projects and domains where the user holds roles. Access is granted to the default project among these.
Root Cause
After troubleshooting, it was discovered that this issue stems from Keystone's core assignment implementation. Specifically, in the following commit:
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 (API Configuration options — keystone 26.0.0.0rc2.dev7 documentation (openstack.org)) in Keystone’s configuration, typically 10 minutes) before changes in group assignments are reflected in OpenStack.
Conclusion
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. (Upstream issue)
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.