LDAP, SAML, OIDC, External Identity, Credential Rotation, and Authentication Troubleshooting: Configuration, Design Choices, and Tradeoffs

1. Central identity versus local identity

Central identity reduces duplicate account administration and lets joiner/mover/leaver processes happen in the enterprise directory or IdP. That is valuable for humans. But Nexus still needs an intentionally protected local recovery path, and automation still needs a noninteractive credential that its package client can actually use.

2. Group mapping is an authorization dependency

External groups are convenient because directory administrators can add/remove people without editing Nexus users. But that also means a directory naming or nesting change can alter repository access. Treat the external group name as part of the Nexus security API contract.

Prefer purpose-built groups such as nexus-repo-readers, nexus-release-publishers, and nexus-repository-operators instead of mapping huge organizational groups. Never map a broad group such as “all-engineering” to nx-admin.

3. Browser SSO versus noninteractive clients

Short-lived federated tokens can improve security when the client and Nexus integration support them, but compatibility is a real constraint. A secure architecture is one the actual client can use without downgrading into plaintext secrets or overbroad fallback accounts.

4. Token/session lifetime and revocation

Browser sessions, IdP sessions, LDAP cached authentication, Nexus User Tokens, format-specific API keys, and CI credentials are separate lifecycles. Revoking one does not necessarily revoke the others immediately.

• LDAP: consider directory disablement plus Nexus LDAP cache behavior when testing revocation.
• SAML: disabling the IdP user prevents future SSO, but current documentation warns that existing Nexus User Tokens remain until separately revoked.
• OIDC: token validation depends on issuer/signature/claim configuration; provider session/logout behavior can differ from Nexus session state.
• Local/CI credentials: rotate in the secret store and prove old credential failure with a controlled request.

5. Realm order and username collisions

Realm ordering matters when the same username exists in more than one source. The safest design avoids ambiguous duplicates for privileged accounts. Keep emergency local administrator names unique and document the expected source of every privileged identity.

If your current version's guide changes, use the current guide and record the chosen order in the runbook. The invariant is not one hard-coded sequence; it is deterministic authentication with a tested recovery path.

6. Fail open is never an authorization strategy

If LDAP, SAML, or OIDC fails, do not enable anonymous access, remove content selectors, broaden repository roles, or map every user to a powerful role. That converts an authentication incident into an authorization incident.

Fail closed means the broken external flow denies access while known recovery identities remain available through a separate, controlled path. Recovery access should be monitored, password-rotated, and used only under an explicit incident procedure.

7. Worked design scenario

An organization has 200 developers, 30 CI jobs, an enterprise IdP, and Community Nexus today. It plans Pro next quarter. Which architecture should it adopt now?

8. Availability, performance, and recovery tradeoffs

External auth latency is not repository blob I/O. LDAP response latency can affect authentication; OIDC/SAML redirects depend on browser/network/IdP latency; repository downloads after authentication still depend on cache, database, blob storage, JVM, and network layers discussed earlier.

Recovery planning must cover both sides of the trust relationship. Restoring Nexus from backup does not restore the LDAP directory or IdP. Conversely, restoring an IdP does not recreate Nexus role mappings. Capture both configuration inventories and verify the relationship after recovery.

9. Knowledge check

10. Next step

Lesson 4 applies the design to incidents. You will diagnose failures from transport inward—connection, bind/redirect, identity lookup, token/assertion validation, group mapping, Nexus authorization—and resist the common mistake of treating every 401, 403, or login loop as the same problem.

Official references and version notes

• Sonatype: Authentication and Realms.
• Sonatype: LDAP — bind/search, user/group mapping, LDAP cache, LDAPS trust.
• Sonatype: SAML — Pro-only browser SSO, metadata, ACS, signing, external role mapping.
• Sonatype: OpenID Connect — self-hosted Pro from 3.86, claim mapping, OAuth2 realm, truststore support.
• Sonatype: Security Management API — users, roles, privileges, realms and Pro OIDC configuration endpoints.
• Sonatype: Authentication Attempt Rate Limiting.
• Self-Hosted Nexus Repository Feature Matrix — LDAP Community/Pro; SAML and User Tokens Pro.
• Sonatype: Download and Java Runtime Compatibility Matrix.

Version-sensitive statements were rechecked on 2026-08-26. The current official direct-download page lists Nexus Repository 3.95.0. Nexus 3.87+ on H2/PostgreSQL requires Java 21. The mandatory learning path is Community-compatible and models external identity with local fixtures; SAML and OIDC are optional Pro-only integrations for self-hosted Nexus.