Skip to content

Group Assignment Changes in Keycloak Not Reflected Immediately in Keystone Authentication (Keycloak + Keystone Integration) #26

@okozachenko1203

Description

@okozachenko1203

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:

Cache list projects and domains for user · 63124f703a - keystone - OpenDev: Free Software Needs Free Tools

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions