Parameterized UserPropertyMapper exposes target user attributes without permission check#51063
Parameterized UserPropertyMapper exposes target user attributes without permission check#51063mabartos wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
Adds authorization checks before exposing user attributes through parameterized scope mappers.
Changes:
- Requires
canViewpermission for resolved users. - Adds privileged and unprivileged integration tests.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
ParameterizedScopeUserPropertyMapper.java |
Adds user-view permission enforcement. |
ParameterizedScopeMapperTest.java |
Tests permitted and suppressed claims. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
services/src/main/java/org/keycloak/protocol/oidc/mappers/ParameterizedScopeUserPropertyMapper.java:80
- This reverses the authorization relationship for the built-in delegation scope. There, the parameter user is the administrator authorized to impersonate the logged-in user, so the logged-in user generally cannot view or impersonate the parameter user; consequently the built-in
may_act.submapper is suppressed and existing delegation flows fail (for example,TokenExchangeDelegationTest.delegation()expects that claim). Preserve the delegation scope's already-validated impersonation semantics while applying this new check to ordinary username scopes.
if (!userPermissions.canView(user) && !userPermissions.canImpersonate(user, client)) {
continue;
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
services/src/main/java/org/keycloak/protocol/oidc/mappers/ParameterizedScopeUserPropertyMapper.java:81
- This impersonation fallback leaves a disclosure path on ordinary
usernamescopes: an unprivileged requester can target any administrator who can impersonate them, and the mapper will expose that administrator's configured attributes even though the requester cannot view the administrator. Only permit this fallback when the mapper belongs to a validateddelegationscope; all other scope types must requireuserPermissions.canView(user).
// allow if the current user can view the target, or the target can impersonate the current user (delegation)
UserPermissionEvaluator targetUserPermissions = AdminPermissions.evaluator(keycloakSession, realm, realm, user).users();
if (!userPermissions.canView(user) && !targetUserPermissions.canImpersonate(currentUser, client)) {
rmartinc
left a comment
There was a problem hiding this comment.
Just a suggestion. Think if it makes sense...
…ut permission check Closes keycloak#51061 Signed-off-by: Martin Bartoš <mabartos@redhat.com>
view-usersis checked (or FGAP). It helps for a normal user-to-user scenario when they need to target themselves. (Do we consider bad admin work?)@keycloak/core-authn Could you please check it? Thanks!
Screencast.From.2026-07-23.14-24-36.mp4