Users, Roles, Privileges, Realms, Anonymous Access, User Tokens, and Least-Privilege Design: Configuration, Design Choices, and Tradeoffs

1. Local identity versus external identity

Local users keep identity state inside Nexus. They are easy to bootstrap and recover, but every joiner, leaver, lockout, password policy, and role assignment becomes repository-administration work. External identity centralizes lifecycle and group membership, but adds an external dependency and mapping layer.

2. Shared account versus dedicated service account

A shared “build” account hides ownership. Multiple pipelines reuse one secret, permissions accumulate to satisfy the union of jobs, and revoking one workload breaks all of them. A dedicated service identity makes one automation boundary observable: owner, repository scope, required actions, credential location, rotation interval, and retirement trigger.

3. Anonymous read convenience versus exposure

Anonymous access can reduce client configuration for intentionally public content. On a private artifact platform, however, it can expose repository names, package versions, internal namespaces, or binaries to any network principal that can reach Nexus. The correct decision depends on the intended audience and network boundary—not on whether configuring credentials is inconvenient.

4. Reusable roles versus privilege creep

Roles should describe stable responsibilities, not accumulated exceptions. A role named ci-publisher that gradually gains delete, repository administration, user management, and wildcard read across formats has stopped representing one responsibility.

Create narrow composable roles, then review the union assigned to each principal. Because Nexus grants are additive, adding one “temporary” broad role can completely undo a carefully designed content-selector or repository role.

5. Token versus password: authorization is unchanged

Credential selection changes how the principal proves identity, not what the principal may do. Keep authorization policy in roles/privileges and test it independently of the chosen credential.

6. Emergency admin versus daily operator

The admin account should be treated as a break-glass/bootstrap identity, not the normal operator persona. A daily repository operator usually needs a much smaller collection of repository-admin, task, browse, or security-read privileges. Keeping the emergency account separate reduces accidental high-impact actions and gives logs a clearer principal identity.

7. Realm order is a compatibility and recovery design

Active realms are ordered. If two authentication sources can claim the same user ID, precedence matters. Keep identities unique across sources when possible. Preserve a proven local recovery path when configuring external realms, and never remove all realms.

Format-specific realms—such as Docker Bearer Token Realm—solve client-protocol authentication requirements. They do not replace repository roles. Conversely, enabling an external browser SSO realm does not automatically make Docker, npm, NuGet, Maven, or automation authentication work.

8. Default role and implicit baseline access

Nexus can provide a default role to authenticated users. This is convenient for a baseline such as UI/search access, but it is another additive grant. When diagnosing “why can this user read that repository?”, include the default role in the complete effective-role inventory rather than reviewing only directly assigned roles.

9. Security configuration and performance

Since 3.89, Nexus uses a permissions cache to reuse computed permissions and automatically clears it when security configuration changes. This reduces repeated authorization computation. Do not disable it as a first troubleshooting step. If authorization seems stale, first reproduce with a controlled request, inspect roles/privileges, and confirm whether the change actually saved before altering runtime settings.

10. Worked decision table

11. Identity runbook fields

For every non-human identity, record: owner/team; purpose; user source/realm; assigned roles; exact repository/namespace actions; credential type; secret-store location (not the secret); creation date; rotation interval; last rotation; expected positive/negative tests; pipeline/application reference; and automatic retirement trigger. For human roles, record the external group or local assignment source and periodic review owner.

12. Knowledge check

13. Summary and next step

Identity design balances lifecycle ownership, recovery, client compatibility, credential hygiene, and least privilege. Lesson 4 uses those principles to diagnose realistic failures without “fixing” them by widening access or bypassing authentication.

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.