Before reporting an issue

• I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

core

Describe the bug

The ParameterizedScopeUserPropertyMapper resolves a username from a parameterized scope parameter and maps the target user's attributes (email, id, firstName, custom attributes, etc.) directly into the token — without checking whether the authenticated user has permission to view the target user's data.

When a client has a username-typed parameterized scope with this mapper attached, any authenticated user can extract profile attributes of any user in the realm — without the view-users role, without fine-grained admin permissions, and without the target user's consent.

The username scope type itself is not the issue — validating that a user exists is a legitimate use case (e.g., marking resources for sharing). The problem is that the mapper crosses the data boundary by resolving user attributes into the token without authorization.

Impact

• Information disclosure — a regular user can extract profile attributes (email, id, firstName, lastName, custom attributes) of any other user in the realm
• No consent from target — the target user never agreed to have their attributes exposed to the requesting user
• Extension risk — custom mappers built on similar patterns may replicate this gap; the built-in mapper should set the correct precedent

Version

Any version with the parameterized-scopes (formerly dynamic-scopes) feature enabled that includes the username scope type (26.7.0+).

Regression

• The issue is a regression

Expected behavior

The ParameterizedScopeUserPropertyMapper should check that the authenticated user has view-users / manage-users permission on the realm-management client (or a matching FGAP policy) before resolving the target user's attributes. Without permission, the user property claims should be suppressed — the scope itself and the raw parameter value (via ParameterizedScopeMapper) can still appear in the token, since the username string was already validated by the scope type.

This is consistent with the DelegationScopeType, which checks canImpersonate() via AdminPermissions.evaluator() before allowing delegation.

Actual behavior

The mapper unconditionally resolves the target user and writes their attributes into the token. The only check is whether the user exists (getUserByUsername returns non-null).

How to Reproduce?

1. Enable --features=parameterized-scopes
2. Create a parameterized client scope share-with with parameter type username
3. Attach a ParameterizedScopeUserPropertyMapper that maps the target user's email to a token claim shared_user_email
4. Assign the scope as optional to a client
5. Authenticate as a regular user (no admin roles, no view-users)
6. Request scope=openid share-with:alice
7. Inspect the access token — it contains Alice's email address in the shared_user_email claim

Anything else?

No response