Bug 57202 - Inconsistent group membership in Keycloak
Inconsistent group membership in Keycloak
Status: NEW
Product: UCS
Classification: Unclassified
Component: Keycloak
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2024-04-02 11:10 CEST by Julia Bremer
Modified: 2024-04-03 17:40 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
json dump of ucs realm configuration from keycloak (108.66 KB, application/json)
2024-04-03 17:40 CEST, Silke Meyer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julia Bremer univentionstaff 2024-04-02 11:10:43 CEST
In a customer environment, we saw inconsistencies in Keycloak group memberships in Keycloak using a "memberUid" group mapper as described in 
https://docs.software-univention.de/keycloak-app/latest/configuration.html#restrict-access-to-applications

The customer saw that in the admin console, you could see the users as members of the Keycloak group,
but if you openened the user, it was missing the group under "group memberships".
This results in the user not getting the role it needs to log into an app.

The LDAP membership was completely consistent. Not that it matters because in this configuration, Keycloak only looks at "memberUid" on the group to calculate group memberships. 

This should not be confused with the normal behaviour when caching is activated.
With the default configuration, there can be inconsistencies for around 5 minutes between the user->groups and the group->user membership.

At the customer, this inconsistency happened only sometimes after adding  group membership, but it was persistent over hours and even outlived a Keycloak container reinitialization.
We were not able to reproduce the issue in a local environment yet and therefore need more information from the customer to analyze the issue in full depth.

It should be noted that the customer had three Keycloak installations of which two were inaccessable to us and could be a culprit due to the shared caching. 
There were no error messages even in the TRACE log level.
Comment 1 Julia Bremer univentionstaff 2024-04-02 11:14:11 CEST
A workaround was needed immediately, and therefore we configured the Keycloak group mapper to react to memberOf on a user instead of memberUid on a group to
calculate group membership. 

This probably inverts the issue at hand, but this is preferrable for this environment, as the needed role is only given to a user if the user itself has the group membership to the group that grants the role.
Comment 2 Silke Meyer univentionstaff 2024-04-03 17:38:54 CEST
The customer provided a dump of their ucs realm configuration, real hostnames, certs/keys were stripped/changed, see attachment.
Comment 3 Silke Meyer univentionstaff 2024-04-03 17:40:04 CEST
Created attachment 11204 [details]
json dump of ucs realm configuration from keycloak