Hi @martin-kanis! The fix looks good overall, I just noticed something that might be worth handling now or at least as a follow up. The same container-only auth pattern also exists on the GET side. The name-based read endpoints in RoleContainerResource check requireView(roleContainer) but not requireView(role) - see getRoleComposites, getRealmRoleComposites, and getClientRoleComposites.

Their ID-based equivalents in RoleByIdResource all check requireView(role). I think we should follow the same pattern and add auth.roles().requireView(role) after the role lookup. Do you think we should also handle this as part of this PR or do you prefer to keep it focused and we address the GET side on a follow up?

Thanks for the PR. Before we proceed, I want to share some analysis of what this change actually does under both RBAC and FGAP evaluation, because I think we need to align on whether this addresses a real security boundary.

No view or manage scopes exist for roles in FGAP

The Roles resource type in AdminPermissionsSchema only defines three scopes: map-role, map-role-client-scope, and map-role-composite. There is no view or manage scope. This means under FGAP, requireView(role) and requireManage(role) have no per-resource scope to evaluate — they cannot provide any finer-grained check than the container-level calls. Should these scopes be added in the future, the PR would become meaningful as defense-in-depth.

Under classic RBAC, requireView(role) is equivalent to requireView(roleContainer)

canView(RoleModel role) delegates directly to the container:

• Realm role → canViewRealm() → requires view-realm
• Client role → canView(client) → requires view-clients

This is identical to canView(RoleContainerModel). So @sguilhen's suggestion to add requireView(role) to the GET endpoints would have no effect under either authorization model today. Again probably meaningful defense-in-depth addition.

Under classic RBAC, requireManage(role) differs from requireManage(roleContainer) only by the isRealmAdminRole guard

canManage(RoleModel role) for realm roles checks canManageRealm() && !isRealmAdminRole(role), while canManage(RoleContainerModel) checks only canManageRealm(). The sole difference is the isRealmAdminRole guard. This is what the PR relies on — a manage-realm holder would be blocked from modifying composites on the built-in admin role.

However, manage-realm is effectively equivalent to realm-admin (still to be implemented)

So the reported scenario (a manage-realm delegate stripping composites from the admin role) is not a real privilege boundary violation — the attacker already has equivalent power.

The PR is valid as defense-in-depth and for consistency with RoleByIdResource, so +1 for having it, but it does not fix a real exploitable vulnerability.

I would like to hear some thoughts, how would you like to proceed with it. For instance, we can merge it and adjust when we are merging the two roles, not sure what to do with the CVE though.

@vramik do you think this should have not been assigned a CVE?