Tenant SAML sign-in
Apply migrations, enable native database user storage, set AUTH_PUBLIC_BASE_URL to the API’s canonical HTTPS origin, and set a shared OIDC_COOKIE_SECRET of at least 32 characters. Configure secret encryption before saving an OIDC client secret. The public origin has no path, query or fragment; callbacks and metadata never derive their origin from the request Host header.
Tenant admins can manage identity providers in the admin console or under /admin/identity-providers. Provider slugs and protocol kinds are immutable. Providers start disabled unless explicitly enabled. Public admin responses contain hasClientSecret and omit ciphertext, plaintext secrets and tenant IDs. Lists use the normal paginated envelope. Disabling or deleting a provider blocks new logins; deactivate its users when existing sessions must also be revoked.
Create a saml provider with idpEntityId, HTTPS idpSsoUrl, one or two idpCertPems, nameIdFormat, and attributeMap for email, display name, groups and the SCIM linking value. Configure explicit administrator, editor or viewer group mappings. autoProvision is false by default; enable it deliberately or pre-provision users through SCIM. A person signing in through different tenant providers receives separate accounts, keyed by provider and subject.
For slug acme and origin https://api.example.com, configure:
| Setting | Value |
|---|---|
| SP entity ID / audience | https://api.example.com/auth/saml/acme/metadata |
| Assertion consumer service, HTTP POST | https://api.example.com/auth/saml/acme/acs |
| SP metadata | https://api.example.com/auth/saml/acme/metadata |
| Application login link | https://api.example.com/auth/sso/acme/login |
Both the SAML response and assertion must be signed. Use SHA-256 signing. Audience, signed subject recipient, issuer, timestamps and request correlation are verified. Only service-provider-initiated browser login is supported: unsolicited IdP-initiated responses fail. Maximum clock skew is 60 seconds; requests and assertions are limited to five minutes. Browser state uses a signed Secure, HttpOnly cookie; SAML’s cross-site POST requires SameSite=None and HTTPS.
The verified assertion is processed by pinned Node-SAML 5.1.0 and the lockfile’s patched XML signature dependencies. The implementation consumes only Node-SAML’s authenticated assertion projection and uses a separate atomic request marker before token minting. See the maintainers’ signature-verification advisory. Keep npm dependency-audit monitoring enabled when upgrading this stack, and rerun the signed, unsigned, expired, audience, recipient, replay and wrapping tests.
Identity-provider setup
AD FS: create a SAML relying-party trust using the SP metadata or the entity ID and POST endpoint above. Use the federation service’s entity ID, SSO endpoint and token-signing certificate in Pulp. Issue a stable NameID and the configured group attributes; sign both message and assertion. Microsoft’s AD FS/SAML migration reference explains the relevant issuer and endpoint values.
Entra: configure a SAML enterprise application with the SP audience and ACS URL above. Use the tenant-specific issuer, login endpoint and application signing certificate. Select Sign SAML response and assertion, then map the expected NameID and group claims. Microsoft documents these certificate signing options and the federation metadata.
Okta: configure a custom SAML application with the SP SSO URL and audience above, signed response and assertion, and group attributes matching the provider’s role mapping. Copy that application’s issuer, SSO URL and signing certificate into the provider. Provisioning can be added through Okta’s application integration workflow.
Rollover and multiple replicas
Add the new signing certificate alongside the old one, switch signing at the IdP, test a fresh login, and remove the old certificate after its overlap window. Updating provider configuration invalidates in-flight login handoffs; start a new login after an update.
Set AUTH_STATE_STORE=redis and REDIS_URL on every replica. auto selects Redis whenever REDIS_URL is configured; otherwise it uses process memory. Memory mode requires one API process or sticky login routing and cannot provide cross-replica handoffs. Redis stores expiring completion codes and SAML request state with atomic consumption. Use the same canonical public origin and cookie secret across replicas. Redis failures fail closed.
OIDC discovery and token/JWKS requests use DNS-pinned outbound requests. Tenant admins cannot make the API reach private networks through provider configuration. An operator can explicitly allow an internal provider using IDP_PRIVATE_ORIGIN_ALLOWLIST, a comma-separated list of exact HTTPS origins; TLS verification and DNS pinning remain enabled. OIDC token endpoints must share the configured discovery origin.
Successful login redirects to the editor with a short-lived, single-use completion code. The editor exchanges it through /auth/oidc/complete; tokens are never placed in redirect URLs. Public status can select providers with ?tenant= or ?email=, and /auth/sso/discover resolves an email domain. Ambiguous domains fail rather than selecting another tenant. External vendor validation remains pending by user decision.