Repository navigation
Membership of hierarchical groups #12726
Replies: 3 comments 5 replies
|
I'd like to add Even reading @hmlnarik 's comment #9482 (comment) I still guess this was initially an accident. If it is NOW considered an "intended behaviour" (even though inconsistant based on order) I need to state: Example: Also I don't see where this simplifies anything. Neither in Keycloaks code nor in any of the handling code (based on Suggestion 1 and Suggestion 2) nor any mental model. See also (https://issues.redhat.com/browse/KEYCLOAK-10603) and #7970 for a very similar issue with users and roles whi 8000 ch has been fixed. |
|
Having checked the code (because I assumed a reason similar to that of #7970 (as solution to the original issue KEYCLOAK-10603)): Due to the issues arising from different ordering of group assignment (first to sub-group then super vs. first to super-group and then to sub-group) not being idempotent I would still see this as a bug and propose to treat it the same as role/user assignment: Split checks into access-check --> transitively checks |
|
In the current implementation if a user is member of a child group first, then added to a parent group, the membership for the child group is not removed. As it's no longer possible to add the user to another child group after it is added to the parent this leads to inconsistencies. In addition the lack of error when trying to add a user to a child group is not good. I see two ways this can be handled:
I don't honestly see any issues with 2, and it is significantly easier to update the behaviour to this than it would be to do 1. This will also allow adding direct child group membership, which still takes affect if membership to a parent is removed, which I can see would be a fairly common thing to want to do. |
|
I agree with 2. The problem with Option 1 I see is exactly the same - there is no easy way to "undo" adding user to a parent group when they were previously member of a child group(s). |
|
I don't know if this is an old post. I am using 19.02 and the behavior I see is that a user can be added to a child group even if the user is a member of a parent group. |
|
Actually using the UI you cannot add a user to a child group if you go through the user. |
|
The fix will only be included in Keycloak 20. @apanagio |
Uh oh!
There was an error while loading. Please reload this page.
Corresponding to #9482, I would like to make a suggestion for improvement on hierarchical groups and start a discussion about it.
Actual state
You have a supergroup1 and a supergroup1/subgroup1.
If a user is member of supergroup1/subgroup1 and you try to add a user to supergroup1 you get an 200 (OK) response, but keycloaks doesn't add the user to supergroup1 because the user is already an indirect member of it.
If you first add the user to supergroup1 and then to supergroup1/subgroup1, the user is member of both groups.
Enhancement
In any case the api should not respond with 200 if the user was not added to the group if it is an (indirect) member of it.
Suggestion 1
Create a configuration parameter for each realm to control whether the user can be added to a group of which he is already an indirect member.
Suggestion 2
Add an parameter ignoreIndirectMembership to the "PUT /{realm}/users/{id}/groups/{groupId}" Endpoint. The parameter should be an optional parameter, with the default value false, so that no existing implementations are damaged.
All reactions