Advanced Claim to Group Mapper resolves group by path rather than ID

Describe the bug

#8467 implemented an OIDC provider mapper along with the frontend logic necessary for selecting a group. However, it stores the group reference as a serialized path rather than by an ID. This is problematic because group names are neither stable nor unique.

Version

17.0.1

Expected behavior

The mapper should store a group by its ID and continue to function after a group is renamed. This aligns with how Group polices are stored and evaluated.

Actual behavior

The user is assigned to the first occurrence of a group with a matching name, and error is thrown when the group is renamed or moved somewhere else in the hierarchy.

There’s additionally an unintentional null pointer exception due to an additional bug where the IdentityBrokerException should be thrown: https://github.com/keycloak/keycloak/blob/bde274465096bf04e65ec07a21fdea7b73efe921/services/src/main/java/org/keycloak/broker/oidc/mappers/AbstractClaimToGroupMapper.java#L83-L85

How to Reproduce?

No response

Anything else?

It seems like groups are only ever resolved by path when importing groups externally, i.e. where the external name informs the name of the group on Keycloak. Since this mapper explicitly configures a target group from a picker UI, I don’t think this behavior is appropriate.

[danielFesenmeyer]

Hi,

one of our customers also stumpled upon this issue.

Their main problem is that the login fails when the group does not (no longer) exist. Furthermore, they would like to have the following behavior when a group is changed in a way affecting the mapper:

• when a group is deleted, the mapper should stay unchanged. The no longer valid group reference should be kept in the mapper
• when a group is moved, the mapper’s group reference should be adjusted accordingly
• when a group is renamed, the mapper’s group reference should also be adjusted

I see the following options to address this issue:

Option 1)

Just change the mapper that it doesn’t fail the login anymore - just log a warning or an error instead. This could be done a) in every case, or b) just when it is configured by means of an additional config option “proceedOnFailure”.

• Advantages: easy to implement, group deletion behavior is as expected
• Disadvantages: group renaming and group move are not addressed as our customer expects

Option 2)

In addition to 1), change the group reference of the mapper to a group ID instead of a group path. In this case, it would be nice to adjust the mapper UI so that the group path is shown in addition to the group ID.

• Advantages: In addition to 1), also group renaming and move are no longer a problem, cause the group ID stays the same in those cases
• Disadvantages: When a group is deleted, there is just the ID reference in the mapper, which does not tell anything about the missing group (in contrast to a group path). Furthermore, a data migration for existing mappers would be necessary. And, which is probably not that important, group references can not be created before the group exists, because the group ID is not yet known

Option 3)

Also includes 1), but in contrast to 2), the group reference remains to be “group path”. In order to handle the move and renaming of groups, a new GroupPathChangeEvent (or even more generic GroupChangeEvent) is introduced, which will be triggered in case of a corresponding group change. (This event interface could be added to org.keycloak.models.GroupModel, there is already a GroupRemovedEvent.) An event handler, which changes the affected mapper data, would be registered (once for all mapper instances) in AbstractClaimToGroupMapper#postInit - or does someone suggest a more appropriate place?

• Advantages: As in option 2), all relevant group changes are no longer a problem. There is no data migration needed. Furthermore, in contrast to option 2) the UI does not need improvement (group path has not to be resolved from group ID).
• Disadvantages: It’s a little challenge where this event handler is instantiated and how it is implemented - it seems like there is no similar functionality yet.

Maybe someone else suggests an additional option?

Regardless of the chosen option, it makes sense to adjust the ClaimToRoleMapper and AdvancedClaimToRoleMapper to behave in a symmetric way.

What do you think (especially the maintainers)?

[danielFesenmeyer]

@mposolda Thanks for your response. I will update the PR in the next days.