-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Description
Description
Groups in Keycloak have a single parent. This constraint is blocking us to address common use cases where a group can be a child of different groups.
So far, two main components are impacted by this constraint:
- LDAP
- SCIM
In LDAP, group entries can reference, or be referenced by, different group entries so that a group can be a child of different groups. See [https://github.com//issues/11752.]
In SCIM, the specification also makes it possible for a group to be a child of different parents. Similar to LDAP, the group schema defines child groups as a member therefore making it possible to share a group as a child of different groups. See [https://datatracker.ietf.org/doc/html/rfc7643#page-25.] For SCIM, this can be a potential blocker or impose limitations to fully support the specification.
In regards to use cases, supporting multiple parents for a group should avoid duplicating groups (and their permissions and members) when they might belong to different (sub) hierarchies. Therefore, improving the manageability of users and groups.
Value Proposition
By supporting a group with multiple parents we should be able to:
- Extend our offerings to support more LDAP use cases and potentially increase our user/customer base
- More flexibility when enabling additional capabilities with a more flexible schema for groups, like SCIM.
Goals
- A group can be a child of different groups
- The Admin Console updated to allow a group to be a member of multiple parents
- The Admin API updated to return and manage group representations where a group can be a member of multiple parents
- The import and export actions updated to represent/process groups with multiple parents
- The LDAP provider updated to import and manage groups with multiple parents
- Documentation updated as it states today that groups can only have a single parent
Notes
- We might want to change the current group schema to remove the reference to the parent group. Instead, we should have a N:N mapping for a group and their members so that a group can be a child of multiple parents. See [https://datatracker.ietf.org/doc/html/rfc7643#page-25|https://datatracker.ietf.org/doc/html/rfc7643#page-25.].
- The implementation should be based on the group schema defined by the SCIM specification in order to be based on an well-known and flexible standard
- We might want to enforce conditions to avoid cyclic relationships when a group is mapped as a child/parent of itself, or when a child group is mapped as a parent of its parent