How to configure keyCloak to understand a two-way user-group binding

We’re looking at switching our product to use keyCloak for authentication and user-management. We have already been using LDAP, and have a wonky setup where we have been storing the user-group relationship on both the user objects and the group objects in LDAP.

For example, a group with user’s “person1” and “person2” would have these attributes (yes, the same group is stored in two different attributes):

member: uid=person1,ou=People,dc=example,dc=com
member: uid=person2,ou=People,dc=example,dc=com
memberUid: person1
memberUid: person2

And a user with groups “group1” and “group2” would have these attributes:

memberOf: cn=group1,ou=Groups,dc=example,dc=com
memberOf: cn=group2,ou=Groups,dc=example,dc=com

Is it possible to configure keyCloak to support this kind of setup? I’ve been able to figure out how create a custom group-ldap-mapper to import groups based on one of these attributes, but I couldn’t find any configuration to have it support reading and updating from all three.

If this isn’t possible to do, that’s fine. We’re wanting to eventually refactor some things to allow us to take out this two-way user-group binding system we have, but it would be nice if this refactoring didn’t have to be done right now.

I think the problem is the first part. The ldap group mapper has an specific attribute to define the membership attribute: " Membership LDAP Attribute “, and, as far as I see is a unique value, so you have to choose either
Membership LDAP Attribute ===> with “member”
Membership Attribute Type” ===> with value DN

OR

Membership LDAP Attribute ===> with “memberUid”
Membership Attribute Type" ===> with value UID

But , AFAIK you have to choose one combination. the field " Membership LDAP Attribute" seems to be a single value field.

1 Like

So, you’re saying keyCloak should support a two-way user/group binding just fine? The main issue I’ll be running into is the fact that our groups hold membership information in two different places on the group object?

OK, thanks for the information. Maybe we can see about just that part up for now, and see what happens.

Blockquote The main issue I’ll be running into is the fact that our groups hold membership information in two different places on the group object?

Yep, your groups have two “MEMBER” attributes. To the best of my knowledge this is something Keycloak cannot manage. You have to choose one … probably the one which is linked to the memberOf.

Alright, thanks for the help!