Users, Roles, Privileges, Realms, Anonymous Access, User Tokens, and Least-Privilege Design: Diagnostics, Failure Modes, Security, and Performance

1. Evidence-first diagnostic sequence

1. Preserve concise evidence: timestamp, sanitized client request, response status, identity expected, endpoint expected.
2. Confirm Nexus version, edition/license, Java/runtime, and whether User Tokens or external realms are actually available.
3. Inspect client URL and authentication method. Distinguish 401-like authentication failures from authorization denials.
4. Inspect active realm order and the user's source.
5. List the user's complete roles, inherited roles, default role, and relevant privileges.
6. Inspect repository type, group membership, content-selector scope, and anonymous policy.
7. Inspect component/asset state only after identity/routing are understood.
8. Inspect proxy/cache/upstream, then database/blob/disk only if evidence points there.
9. Inspect sanitized logs/metrics/tasks.
10. Change the smallest security object, retest the same request, then remove temporary diagnostic state.

2. Failure: bootstrap admin remains a daily/automation credential

Symptom: builds succeed, but every CI request is attributed to admin; the credential can also create users, delete repositories, and modify security settings.

Cause: the bootstrap identity was reused as a convenience credential. There may be no application error at all—the failure is excessive authority.

Correction: create a dedicated service identity with only required repository-content privileges, migrate the pipeline secret, prove positive/negative tests, then retire the admin credential from automation. Do not disable the only recovery account until a tested recovery path exists.

3. Failure: a role that looks narrow inherits or coexists with a broad grant

Symptom: a CI identity with a “publisher-no-delete” role can delete artifacts or read unrelated repositories.

Cause: another direct role, inherited role, default role, wildcard privilege, repository-view privilege, or group privilege grants the action. Nexus privileges do not deny access granted elsewhere.

curl -fsS --netrc-file "$NX_AUTH_FILE" "$NX_URL/service/rest/v1/security/users?userId=ch15-svc-ci"   > "$LAB/evidence/diag-user.json"
curl -fsS --netrc-file "$NX_AUTH_FILE" "$NX_URL/service/rest/v1/security/roles"   > "$LAB/evidence/diag-roles.json"
curl -fsS --netrc-file "$NX_AUTH_FILE" "$NX_URL/service/rest/v1/security/privileges"   > "$LAB/evidence/diag-privileges.json"

Correction: remove only the unintended grant, then rerun the exact denied operation. Do not add a “deny” role; Nexus grants are additive.

4. Failure: realm ordering or enablement is mistaken for permissions

Authentication failure: a previously valid user cannot authenticate after realm changes, or a name collision resolves against a different source.

Authorization failure: the principal authenticates successfully but receives a denial on a repository action.

Inspect GET /service/rest/v1/security/realms/active and .../available before changing order. If authentication succeeded, stop changing realms and inspect roles/privileges. Never remove all active realms while experimenting.

5. Failure: credential printed in logs or command lines

Symptom: a password, User Token passcode, API key, or Basic Authorization material appears in CI logs, shell history, process listings, support bundles, screenshots, or committed client config.

Correction: treat the credential as compromised. Rotate/revoke it first; then remove/redact leaked copies and fix the secret-injection method. Do not merely delete the log while leaving the credential valid.

6. Failure: stale service account after a pipeline is removed

Symptom: a non-human user still has active repository privileges weeks after the owning job/repository/application was retired.

Cause: account lifecycle was never linked to workload lifecycle.

Correction: disable or remove the service identity after confirming no active owner, capture the change ticket/evidence, and add a runbook field linking every service account to an owning pipeline and review date. Credential rotation does not solve orphaned authorization.

7. Failure: anonymous access reaches an internal group

Symptom: unauthenticated direct access to a private hosted repository fails, but the same artifact downloads through a group.

Cause: the group endpoint has an anonymous-compatible read grant or format-specific anonymous behavior. Direct member restrictions do not prove group restrictions.

Correction: inspect global anonymous settings, the anonymous role, group privileges, member order, and format-specific repository settings; narrow or disable only the offending grant, then retest direct and group endpoints without credentials.

8. Intentionally broken example: “fix” a 403 by adding nx-admin

Observed: ch15-svc-ci receives 403 on DELETE /service/rest/v1/assets/<id>
Bad response: assign role nx-admin so the request succeeds.
Result: the symptom disappears, but the service account can now administer the entire instance.

The original 403 may be the correct security outcome because the service account was never supposed to delete. A successful request after adding nx-admin is not evidence of a fix; it is evidence that authorization was bypassed by excessive privilege.

The correct repair is to restate the intended action. If CI should not delete, preserve the denial. If it truly must delete, add the smallest repository/content-selector delete privilege and test that unrelated actions remain denied.

9. Permissions cache and “stale access”

Nexus 3.89+ caches computed permissions and automatically clears the cache when security roles/authorization change. If access appears stale, first verify that the security object was actually saved, the request authenticates as the expected principal, and the client is not reusing another credential. Do not disable the permissions cache or restart Nexus as a default correction.

10. Performance boundaries

11. Security-sensitive mutations

Changing admin passwords, User Tokens, realms, anonymous settings, roles, privileges, content selectors, LDAP/SAML/OIDC configuration, or package-client credentials can lock out users or expose repositories. Use a disposable target, preserve before-state, maintain a tested recovery administrator, change one object at a time, and verify with both allowed and denied requests.

12. Knowledge check

13. Summary and next step

Identity incidents are solved by distinguishing authentication, authorization, endpoint routing, and credential lifecycle. Lesson 5 integrates those ideas into a four-role checkpoint that proves positive/negative access, rotation, anonymous denial, and full cleanup.

Official references and version notes

• Sonatype: Access Control — RBAC object model, default roles, additive grants, and least privilege.
• Sonatype: Users and Roles.
• Sonatype: Privileges — repository, application, selector, and wildcard privilege semantics.
• Sonatype: Realms and Authentication.
• Sonatype: Anonymous Access.
• Sonatype: User Tokens and User Tokens API.
• Sonatype: Security Management API and API Reference.
• Self-Hosted Nexus Repository Feature Matrix — User Token Support and enterprise identity boundaries.
• Sonatype: Download and 2026 self-hosted release notes.

Version-sensitive statements were rechecked on 2026-08-26. Sonatype's current official self-hosted download page exposes Nexus Repository 3.95.0 (archive build 3.95.0-07), while version-index pages may lag. The mandatory chapter path is Community-compatible: local users, roles, privileges, realms, anonymous-access settings, Raw repositories, and temporary passwords. Self-hosted User Token Support is Pro-only and appears only as an optional extension or fixture.