8000 Allow extending fine-grained admin permissions for groups to their children by baptistegh · Pull Request #55019 · keycloak/keycloak · GitHub
[go: up one dir, main page]

Skip to content

Allow extending fine-grained admin permissions for groups to their children - #55019

Draft
baptistegh wants to merge 1 commit into
keycloak:mainfrom
baptistegh:43865-group-permission-extend-children
Draft

baptistegh wants to merge 1 commit into
keycloak:mainfrom
baptistegh:43865-group-permission-extend-children

Conversation

@baptistegh
Copy link
Copy Markdown

Closes #43865

Decisions

  • Opt-in flag: existing permissions keep their behavior, so there is no upgrade impact. The flag is rejected for resource types other than Groups, for permissions without specific groups, and outside admin permissions.
  • Most specific wins: a subgroup's own permission for a scope always decides that scope. Otherwise the closest extended parent decides, so a subgroup can be extended to override its parent. An inherited permission only decides the scopes not already decided lower down, even if it has more scopes.
  • Member scopes: for view-members and the other member scopes, a deny from any extended parent wins. This matches how member scopes already cascade for users, so group-level checks, user checks and search agree.
  • Search: group and user search include inherited permissions, so members of subgroups now appear in user search when view-members is extended (partially addresses Unable to view childgroup users with view-members permission on the parent group #16966).
  • No cost without the option: the parent walk and the search expansion are skipped when no extended permission exists in the realm.

Known limitations

  • Search walks each extended group's subtree with one query per subgroup, so its cost grows with the hierarchy. A single recursive query is not portable through JPA across the supported databases, so I would like your input on the approach.
  • A permission without policies (only possible through the REST API) counts as the subgroup's own permission in direct checks but not in search.

Testing

New GroupResourceTypeExtendChildrenTest (18 tests) and two Playwright tests for the permission form. All 292 tests in org.keycloak.tests.admin.authz.fgap pass.

…ildren

Adds an opt-in "Extend to children" option (extendChildren in the REST API) to admin permissions for specific groups. When enabled, the permission also applies to all the subgroups of the selected groups, including subgroups created later, so that the administration of a group hierarchy can be delegated.

A subgroup's own permission for a scope takes precedence over inherited ones. For group scopes, the closest ancestor with an extended permission decides. For member scopes, a deny from any extended ancestor wins, consistently with the existing member scope cascading. Inherited permissions are also taken into account when searching groups and users.

Closes keycloak#43865

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Baptiste Gouhoury <gouhoury.baptiste@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add "extend to children" capability for group permissions in FGAP v2

1 participant

0