[Security][Critical] Scope workspace-admin user operations to prevent cross-tenant account takeover

[BechsteinDigital]

Severity

Critical / release blocker

Problem

Workspace admins receive user.update, user.delete and related permissions. Authorization only verifies that the target user belongs to the caller's workspace, but the subsequent operations mutate or erase the global BackendUser.

A workspace admin can therefore:

• replace the global email, display name and password of a member;
• delete the global user, every workspace membership and global RBAC assignment;
• export memberships and audit information belonging to other workspaces.

This becomes a cross-tenant account takeover if the victim belongs to multiple workspaces and can escalate further if a platform operator is also a workspace member.

Evidence

• src/Core/Application/Security/WorkspaceRolePermissions.cs:20
• src/Administration/Api/UserEndpoints.cs:91
• src/Administration/Api/UserEndpoints.cs:127
• src/Administration/Api/UserEndpoints.cs:157
• src/Administration/Api/UserEndpoints.cs:195
• src/Core/Infrastructure/Persistence/EfUserDataSubjectService.cs:32
• src/Core/Infrastructure/Persistence/EfBackendUserStore.cs:145

Required change

Separate workspace membership administration from global identity administration. Workspace admins may only manage membership and workspace role inside their own workspace. Global credentials, account erasure and data-subject export must be operator-only.

Acceptance criteria

• Workspace-scoped APIs cannot mutate global credentials or delete/export a global user.
• A dedicated workspace-membership use case manages only the selected workspace.
• Global identity operations require an explicit platform permission.
• Tests cover a victim in two workspaces.
• Tests cover a platform operator who is also a workspace member.
• Tests verify that exports never disclose another workspace to workspace admins.