Federation protocols and provisioning

OIDC, OAuth and PKCE

Registered OIDC clients use browser authorisation, account selection, consent and terms where configured. Device authorisation is a separate interface, not a replacement for client registration. PKCE and higher-assurance options depend on client and tenant policy. PAR, private-key JWT, mTLS, DPoP and FAPI profiles are conditional; their presence in source does not mean they are enabled.

1. Register exact issuer, redirect and response settings for the client.
2. Complete consent and account selection; verify identity and audience.
3. Confirm PKCE or assurance support in policy; do not weaken validation to clear a denial.

SAML and remote logout

SAML service- and identity-provider routes expose metadata and browser assertion flows. Configure the connection through SAML management. Validate issuer, audience, reply destination, signature and time conditions with the partner. Logout is separate: local revocation does not prove that every relying-party cookie or session was cleared.

1. Compare connection metadata, signing key and endpoints with the partner.
2. Test a signed assertion; verify tenant, subject, membership and expiry.
3. Use supported logout controls and distinguish local revocation from remote sign-out.

SCIM and directory sync

Provisioning is distinct from interactive federation. SCIM schema and reconciliation coexist with directory connectors that use an enrolled customer-side agent. Imports preserve tenant provenance and quarantine conflicts; email alone does not link accounts. The server does not ship the customer agent binary.

1. Register the tenant target and map supported attributes and immutable identity keys.
2. Run a controlled sync; inspect results and resolve quarantines in the tenant workflow.
3. Deploy and enroll the compatible agent separately before queuing connector work.

CAS, WS-Federation and RADIUS

CAS requires explicit enablement. WS-Federation and WS-Trust remain disabled unless an allowed registration or policy enables them; realm, audience, reply, membership, signature and expiry checks remain mandatory. RADIUS uses an optional signed agent, not a site listener. Its maintained reference prefers RADIUS/1.1 over TLS or DTLS; legacy UDP is private-network compatibility only.

1. Check protocol enablement and client registration before testing CAS or WS-Federation.
2. For RADIUS, confirm customer agent, tenant connector and permitted transport.
3. If disabled or unenrolled, resolve setup instead of switching protocols to evade policy.

Registration and credentials

Client registration must remain within its owning tenant and application. Dynamic registration, private-key JWT, mTLS and FAPI references describe conditional contracts, not universal enablement. Keep private keys with their owner and rotate or revoke credentials using the matching management control. Agent keys are not OAuth client credentials.

1. Gather owner, tenant, redirect or metadata, scopes and credential type.
2. Store any returned secret securely; rotate or revoke it through management.
3. For agent enrollment, create the private key on the customer side and submit its CSR.

Contract and troubleshooting

Use /api/auth/management/openapi.json for current management operations, fields and security. Maintained protocol notes cover narrower connector and assurance behaviour. Common failures include wrong tenant, unregistered redirect, stale metadata or certificate, disabled profile, invalid signature, SCIM quarantine or revoked agent. Correct the relevant trust boundary; do not disable verification.

1. Check the OpenAPI schema and security requirements for the operation.
2. Compare safe error details and registered values with current provider metadata.
3. Retest the controlled flow and confirm identity or sync state before rollout.

Frequently asked questions

Related pages

• Single sign-on and identity
• SSO administration
• Identity governance and privileged access
• Private application access