Enterprise federation with SAML and OpenID Connect

Federation passes authentication information from an identity provider to an application. Check claims, sessions, account changes and the permissions applied by the receiving service.

Overview#

Federation lets one security domain rely on authenticated identity information from another. SAML 2.0 and OpenID Connect (OIDC) are widely used for operator sign in and application session establishment. Apply the OASIS SAML Version 2.0 Errata 05 alongside the base SAML publications; its clarifications affect interoperability and security sensitive processing. Neither federation family, by itself, provisions accounts, proves a requested physical action is safe, or grants access to doors, video, alarms, intercom, or evidence. SAML SAML ERRATA OIDC NIST FED

Protocol and responsibility boundaries#

OAuth is an authorisation framework. OIDC adds an authentication layer. A valid OAuth access token isn't necessarily evidence of an interactive user login, and a valid OIDC ID Token is intended for its client, not as a general API bearer credential. Follow RFC 9700 for OAuth security decisions. OAUTH BCP

Trust model and onboarding#

Federation requires configured trust relationships as well as signature verification. Establish the following during controlled onboarding:

• exact issuer/entity identifier and environment;
• allowed SAML endpoints/bindings or OIDC discovery issuer and endpoints;
• trusted signing and, where used, encryption keys and algorithms;
• service provider entity ID or OIDC client ID and exact redirect URIs;
• subject identifier semantics and tenant/organization mapping;
• required authentication context or assurance information;
• approved attributes/claims and their authoritative source;
• clock skew, assertion/token lifetime, nonce, replay, and session policy;
• key rollover, emergency revocation, metadata/discovery refresh, and rollback ownership.

Don't dynamically trust an issuer, metadata URL, discovery URL, or key set supplied by an untrusted login request. Discovery and metadata retrieval are privileged configuration inputs: constrain scheme, host, redirects, size, parser behaviour, refresh, and change approval.

Stable identity mapping#

Use a protocol stable, issuer scoped subject key:

federated identity key = trusted issuer + protocol subject identifier

For OIDC this is normally the iss and sub pair. For SAML, define the accepted issuer plus NameID format/value or another contractually immutable identifier. Email address, display name, username, group display name, employee number, or certificate common name may change or collide and shouldn't be the sole durable key unless an authoritative contract guarantees its scope and lifecycle.

Pairwise subject identifiers reduce cross service correlation but require explicit account linking design. Never merge two local operator records solely because an email like claim matches. Make account linking an authenticated, audited, reversible process with collision handling.

SAML 2.0 validation profile#

SAML uses XML and supports multiple profiles and bindings. Pin the profile rather than accepting any syntactically valid SAML message. SAML CORE SAML PROFILES

For Web Browser SSO, validate at least:

1. expected response type, binding, destination, and service provider endpoint;
2. trusted response/assertion issuer and signature according to the deployment profile;
3. signature algorithm, digest algorithm, certificate/key, and key rollover policy;
4. assertion audience restriction, recipient, subject confirmation method, and InResponseTo when request correlation applies;
5. NotBefore and NotOnOrAfter under bounded clock skew;
6. replay of response/assertion identifiers for their useful lifetime;
7. required authentication context and attribute schema;
8. RelayState integrity and its binding to locally stored request state;
9. one unambiguous assertion/subject/attribute set after validation.

XML and signature wrapping safety#

• Disable external entities, DTD processing, XInclude, and external resource retrieval.
• Bound document bytes, element depth/count, attributes, text, base64 values, and decompressed request size.
• Reject duplicate XML IDs and ambiguous duplicate protocol elements.
• Verify the signature reference and then consume the exact validated element; don't validate one assertion and read identity from another.
• Avoid permissive “find first assertion anywhere” logic.
• Apply schema/profile validation and business validation; a cryptographic signature alone doesn't make every claim acceptable.
• Keep encryption keys separate from signing trust and reject unsupported algorithm/key combinations.

Whether the SAML Response, Assertion, or both must be signed is a deployment profile decision. State it explicitly; don't accept either opportunistically.

OpenID Connect validation profile#

OIDC Core defines authentication using OAuth 2.0 protocol elements. Prefer Authorisation Code flow and apply the current OAuth security BCP. OIDC OAUTH BCP

Authorisation request and response#

• Use an exact preregistered redirect URI; never use substring, wildcard, or open redirect matching for sensitive clients.
• Generate high entropy state and bind it to the browser session and intended return context.
• Use PKCE with a strong challenge method for authorisation code interception protection; PKCE doesn't replace state or client authentication.
• Generate and validate a nonce for OIDC flows where required by the profile and bind it to the transaction.
• Prevent mix up by binding the response to the expected issuer and authorisation server.
• Keep authorisation codes out of logs, referrers, browser history, and analytics where practicable; redeem once over protected transport.

ID Token#

Validate:

• exact iss match to the configured issuer;
• aud contains the client ID and azp is handled where required;
• signature against a trusted, refreshed issuer key set under an algorithm allowlist;
• exp, iat, and any required nbf with bounded clock tolerance;
• expected nonce and authentication context/age where required;
• token type/use so an access token or token from another environment can't be substituted.

Don't select an arbitrary key solely by attacker controlled header data. Bound JSON/token/header/key set size, reject duplicate security critical JSON members, and define behaviour for an unknown key ID during controlled key refresh.

Access tokens and UserInfo#

An API validates access tokens according to the authorisation server profile: issuer, resource audience, signature or introspection result, token type, lifetime, client/subject, scopes, confirmation/sender constraint where used, and revocation/cache policy. It then authorises the exact object and action.

The OIDC client must verify that UserInfo sub exactly matches the ID Token sub. Treat other claims as untrusted for authorisation unless the federation contract makes them authoritative and current.

Claims, groups, and role mapping#

Federated claims are inputs to local policy, not automatically local permissions.

• Allowlist accepted claim names, types, cardinality, namespace, issuer, and maximum size.
• Distinguish absent, empty, false, unknown, and explicitly removed values.
• Map external groups to narrowly scoped local roles through reviewed configuration.
• Prevent a tenant administrator from minting a group name that collides with a privileged platform group.
• Define nested group expansion, overage/truncation behaviour, replication delay, and stale session handling.
• Record mapping/policy version with every privileged authorisation decision.
• Require local step up, approval, reason, and safety prerequisites for high impact operations where appropriate.

An IdP administrator able to alter claims can indirectly affect application access. Include federation configuration, claim rules, signing keys, and privileged group administration in the threat model and audit scope.

Federation, provisioning, and deprovisioning#

Just in time account creation helps onboarding but doesn't guarantee prompt disablement. A session or refresh token can outlive an upstream account change, and a user who never logs in again may never trigger cleanup.

Use SCIM identity provisioning, a directory connector, or another reconciled lifecycle channel for joiner/mover/leaver state. Define which system owns display data, employment status, role membership, credential assignment, site scope, and deletion. Reconcile periodically rather than assuming individual events are complete.

Keep identity federation separate from physical credential lifecycle:

enterprise identity status
  -> application account and operator roles
  -> approved PACS identity/credential workflow
  -> controller policy distribution
  -> presentation and physical-access decision

Disabling application SSO doesn't prove cards, mobile credentials, PINs, cached controller rights, or existing sessions were revoked.

Sessions, logout, and token lifetime#

• Set absolute and idle application session limits according to consequence.
• Regenerate session identifiers after authentication and privilege change.
• Use secure, HttpOnly, appropriately scoped cookies and a deliberate SameSite/CSRF policy.
• Reauthenticate or step up before sensitive exports, role changes, credential administration, overrides, and physical commands.
• Recheck authorisation for long running jobs and streams.
• Treat front channel/back channel/single logout as a profile with partial failure states; local logout, IdP logout, token revocation, and all relying party sessions are different outcomes.
• Never make emergency egress or certified life safety operation depend on a browser session or live IdP.

Availability and break glass#

Define behaviour when DNS, time, metadata, key discovery, the IdP, token endpoint, directory, or upstream MFA is unavailable. Avoid both silent fail open and total loss of safely required local administration.

A break glass identity should be local only where necessary, minimally privileged, independently protected, monitored, tested through an approved exercise, and followed by credential rotation and review. It must not become the routine answer to federation outages.

Audit and privacy#

Record trusted issuer, subject key, client/service provider, authentication context, session ID in non reusable form, claim mapping version, local role/policy decision, target tenant/resource/action, correlation ID, outcome, and administrative configuration changes. Don't log assertions, ID Tokens, access tokens, authorisation codes, private keys, or unnecessary identity attributes.

Federation logs can reveal employment, role, location, access, and incident response information. Minimize collection, restrict access/export, define retention, and preserve source and receive time separately.

Review checklist#

• SAML profile/bindings or OIDC flow and exact issuer/client/service provider identifiers pinned
• Metadata/discovery/key retrieval constrained and key rollover/revocation rehearsed
• Stable issuer scoped subject key used; account linking handles collision and recovery
• SAML destination, audience, recipient, time, correlation, replay, signature, and exact signed object validated
• XML parser and signature wrapping defenses enforced
• OIDC state, PKCE, nonce, issuer, audience/authorised party, time, algorithm, and token type validated
• ID Tokens rejected as general API access tokens; UserInfo subject matched
• External claims/groups mapped through typed, scoped, versioned local policy
• Provisioning/deprovisioning and active session revocation reconciled separately
• Federation success kept separate from application, PACS, and physical authorisation
• Outage, break glass, logout, privacy, and audit behaviour documented

Sources#

• SAML, SAML 2.0 standard documents, OASIS.
• SAML ERRATA, SAML Version 2.0 Errata 05, OASIS Approved Errata, 1 May 2012.
• SAML CORE, Assertions and Protocols for SAML V2.0, OASIS Standard.
• SAML PROFILES, Profiles for SAML V2.0, OASIS Standard.
• OIDC, OpenID Connect Core 1.0 incorporating errata set 2, OpenID Foundation, December 2023.
• OAUTH BCP, RFC 9700 / BCP 240: Best Current Practice for OAuth 2.0 Security, IETF, January 2025.
• NIST FED, NIST SP 800-63C-4: Federation and Assertions, NIST, July 2025.

Section overview · Wiki home