System users can be disabled — EnableUserAsync has no system-user guard

[lubomirw]

Description

UserService.UpdateAsync (src/Auth/Services/UserService.cs:69-72) and DeleteAsync (:78-80) both reject system users with InvalidActionException, but EnableUserAsync (:272-280) sets user.Enabled with no such check.

Core does not compensate: UserManagementServiceImpl.enableUser and disableUser are gated only on USER:ENABLE and contain no systemUser check either. So the enable/disable path is unguarded on both sides, while every other mutation of a system user is refused.

Consequence: any holder of USER:ENABLE can disable the acme, scep, cmp, localhost or attribute-content-resolver system users, breaking the flows that authenticate as them — ACME, SCEP and CMP enrolment stop working, and attribute dereferencing on the operation path fails.

The fix belongs beside the existing guards in UserService: reject when user.SystemUser in EnableUserAsync, covering both enable and disable.

Note that OmniTrustILM/core#1915 adds a defensive check on core's own enableUser/disableUser, but that only covers callers arriving through core. The auth API is independently reachable, so the authoritative guard has to live here.

Discovered while hardening system-role and system-user handling for the auditor role work (OmniTrustILM/ilm#307). The gap is pre-existing and independent of that feature.

Steps to Reproduce

1. Authenticate as a user holding only USER:ENABLE.
2. Disable the acme system user — PATCH /v1/users/{acmeUserUuid}/disable through core, or the equivalent auth endpoint directly.
3. Attempt an ACME order.

Expected Behavior

The request is refused, the same way updating or deleting a system user is refused: InvalidActionException, "Cannot update system user."

Actual Behavior

The system user is disabled and the protocol it backs stops working.

Severity

Major

[lubomirw]

Scope note from review of OmniTrustILM/core#1915: this applies to role membership as well as enable/disable.

core#1915 adds guards so that a role paired with a system user takes no human members and its system user cannot be detached (by clearing the user's roles, by removeRole, or by a membership replacement that omits it), that a system user holds only its own role, and that a role granting all resources can only be granted by someone who already holds it.

All of those are core-side only. The auth API is independently reachable, and RolesController.AssignUsersAsync plus the users/roles endpoints carry no equivalent check — so anything that talks to the auth service directly bypasses every one of them. Role sync from JWT claims in UserService is a second path, since it assigns roles by name from token claims and can create unknown roles when enabled.

So the authoritative versions of these checks belong here, next to the existing "Cannot update system user" / "Cannot delete system role" guards, rather than only in core. Suggest widening this issue to cover membership alongside the enable/disable gap it was filed for, or splitting it if that reads better.