[keycloak-dev] New feature implementation: Namespace support for LDAP group mapper by storing the groups synced from LDAP provider within a customizable path

Jürgeleit Torsten torsten.juergeleit at gmail.com
Sun Jul 15 17:03:00 EDT 2018


Hi Keycloak Team,

we’re using MSAD group memberships for provisioning roles in different applications (JIRA, SonarQube, GitLab, …). The required information (application, project, role) is encoded in the MSAD group name via patterns like “<prefix>_<app>_<project>_<role>”, e.g. “G_APPL_JIRA_PR1_Developer”. Currently in every application the corresponding MSAD group memberships are retrieved via an LDAP query (with filter using the application-specific prefix) and stored the application’s internal user access management system.

Now we would like to introduce Keycloak as the central IdP for these applications. But currently Keycloak only supports syncing groups from LDAP federation provider as top-level KC groups. This approach has some limitations:
If using multiple group mappers then there’s no way to isolate the KC groups synched by each group mapper.
If the option "Drop non-existing groups during sync” is activated then all KC groups (including the manually created ones) are deleted.
There’s no way to inherit roles from a parent KC group.

Therefore I would like to propose adding some kind of namespace support to GroupLDAPStorageMapper. This could be implemented by an additional config property for a Keycloak group path where the groups synched from LDAP provider are stored (defaults to “/“ for top-level groups).

An implementation of this approach can be found in commit baa76c6 <https://github.com/tjuerge/keycloak/commit/baa76c6d591a0be1b16612470030f675b41ac93c> of my fork. To test this implementation modified copies of existing integration tests are used (here the groups are stored within the path "/Applications/App1” instead of “/“). 

WDYT?

Cheers,
Torsten


More information about the keycloak-dev mailing list