Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-13766

Groups from LDAP User Federations loose sync in READ_ONLY when disabled

    Details

    • Type: Enhancement
    • Status: Triage (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 7.0.0
    • Fix Version/s: None
    • Component/s: User Federation - LDAP
    • Labels:
      None
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      I'm having trouble with a certain scenario where i want to migrate from LDAP User Federations to Identity Providers.

      This issue is a little bit complex so i will first try to explain my environment before explaining the problem:

      Environment description
      I am running a Keycloak 7.0.0 Standalone HA Cluster (2 nodes) with a LDAP replication cluster (also 2 nodes) and LDAP load balancer.

      The structure for Keycloak is that each customer I manage gets its own realm which is mapped (for historic reasons) to a similar LDAP subtree:

      <Keycloak Realms>
      - master
      - Customer A
      - Customer B
      - ...
      
      <LDAP>
      dc=my,dc=ldap
      -- ou=Groups
      ---- ou=Customer A
      ---- ou=Customer B
      -- ou=People
      ---- ou=Customer A
      ---- ou=Customer B
      

      That guarantees that data is separated for each customer in a LDAP subtree. Because LDAP is used as backend I configured Keycloak with LDAP user federations. Each Realm (Customer) has at least one User Federation where users and groups are gathered from the matching subtree e.g. for Customer A

      • Users: ou=Customer A,ou=People,dc=my,dc=ldap
        • Federations is set to WRITABLE
      • Groups: ou=Customer A,ou=Groups,dc=my,dc=ldap
        • Mapper is set to READ_ONLY and LOAD_GROUPS_BY_MEMBER_ATTRIBUTE

      Also I have the use case where users from other realms should be granted membership to groups of Customer A. Because I was not experienced with Keycloak when setting things up I mapped another LDAP User Federation to the realm with the Foreign LDAP connection like so:

      Current Realm: Customer A
      User Federation (Customer A):

      • Users: ou=Customer A,ou=People,dc=my,dc=ldap
        • Federations is set to WRITABLE
      • Groups: ou=Customer A,ou=Groups,dc=my,dc=ldap
        • Mapper is set to LDAP_ONLY and LOAD_GROUPS_BY_MEMBER_ATTRIBUTE

      User Federation (Customer B):

      • Users: ou=Customer B,ou=People,dc=my,dc=ldap
        • Federations is set to READ_ONLY
      • Groups: ou=Customer A,ou=Groups,dc=my,dc=ldap
        • Mapper is set to LDAP_ONLY and LOAD_GROUPS_BY_MEMBER_ATTRIBUTE

      I could now grant users from Customer B memberships in Customer A's groups.

      Use Case
      The described environment should now be moved to a setup where User Federations are replaced with Identity Providers. Instead of mapping Customer B's LDAP directory in a User Federations, I want to use the Customer B Realm as Identity Provider.

      For the users using Keycloak nothing should change so I want to migrate as much information as possible. One critical information is the group memberships.

      Problem
      I was able to find a setup which "migrates" the user from LDAP to a local Keycloak User and link those to an Identity Provider. However, it fails when I want to disabled or remove the User Federations because the memberships in the groups are removed.

      Eventually i figured out two things (based on the example above):

      1. I have two User Federation mappers handling the same groups from LDAP. So disabling one may cause new side effects
      2. The settings of either the User Federation or the mapper was a Read Only Setting where LDAP would be respected as master source. The Keycloak database was merely a cache

      Conclusion
      To solve my problem i changed the settings of the user federation (and mapper) so that all users and groups would be synced to the Keycloak database. Here is the current idea which was supposed to work:

      Current Realm: Customer A
      User Federation (Customer A):

      • Users: ou=Customer A,ou=People,dc=my,dc=ldap
        • Federations is set to UNSYNCED
      • Groups: ou=Customer A,ou=Groups,dc=my,dc=ldap
        • Mapper is set to READ_ONLY and GET_GROUPS_FROM_USERS_MEMBEROF_ATTRIBUTE

      User Federation (Customer B):

      • Users: ou=Customer B,ou=People,dc=my,dc=ldap
        • Federations is set to UNSYNCED
      • Groups: ou=Customer A,ou=Groups,dc=my,dc=ldap
        • Mapper is set to READ_ONLY and GET_GROUPS_FROM_USERS_MEMBEROF_ATTRIBUTE

      The idea was that the LDAP data is not treaded as superior but always merged with the Keycloak data.
      This worked until i decided to disable the user federations and unlink the users. When disabling any of my federations and save it the group memberships will be erased for either Customer. When I disable the User Federation for Customer A then all memberships of Customer B remain and vice versa. I am not entirely sure but it seems like a bug to me that the groups are overridden in such a way because the READ_ONLY settings is supposed to merge the memberships in the Keycloak database with the LDAP data.

      Update: I figured out that the User Federation sync is like a shallow group membership. If I assign a user to a group after syncing and then turn off the federations everything is kept. But that would require me to re-save all users groups explicitly before disabling the UFs.
      I went a bit deeper from that point on and peeked into the db table USER_GROUP_MEMBERSHIP. This table is empty. So the sync settings do not persist any information in Keycloak as i was expecting (or i simply look into the wrong table).

      TL;DR
      I have multiple LDAP User Fedarations which shall now be Identity Providers. When disabling the User Federations i loose data and i don't know if it is a bug or expected behavior and how to achieve my goals in "migrating" to IdPs. It seems like the group memberships from LDAP are not written into the Keycloak DB.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                kprein Kevin Kortum
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: