yahoo-eng-team team mailing list archive

[Oleksandr Kozachenko <2083004@xxxxxxxxxxxxxxxxxx>]

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