SSO / SAMLSingle Sign-On / Security Assertion Markup Language

SSO federates authentication — the user proves identity once to a central IdP, and the SP accepts the IdP's assertion. SSO is not authorisation (what the user is allowed to do), not provisioning (where the account is created), and not account lifecycle (joiner / mover / leaver flows). Those are RBAC, SCIM and IGA respectively — all separate but adjacent disciplines.

Web SSO with SAML uses the HTTP-POST or HTTP-Redirect binding. SP-initiated flow:

• User hits SP at https://app.example.com — SP detects no session.
• SP generates a SAML AuthnRequest XML, signs it (optional but recommended), redirects browser to the IdP's SSO URL with the AuthnRequest as a query parameter.
• IdP authenticates the user (password + MFA, smart card, conditional access).
• IdP issues a signed SAML Response containing an Assertion with NameID + AttributeStatement + AudienceRestriction; HTTP-POSTs it back to the SP's Assertion Consumer Service (ACS) URL.
• SP validates the signature against the IdP's metadata-published X.509 certificate, validates Conditions (NotBefore, NotOnOrAfter, Audience), creates a local session.

IdP-initiated flow skips the AuthnRequest — the user starts at the IdP's app catalog tile, the IdP POSTs an unsolicited Response to the SP. Convenient for app dashboards; weaker against CSRF unless the SP enforces RelayState validation.

OpenID Connect is a thin identity layer on top of OAuth 2.0. The authorisation-code flow with PKCE is the recommended pattern:

• User hits SP — SP redirects to IdP's /authorize endpoint with response_type=code, client_id, redirect_uri, scope=openid profile email, state, code_challenge.
• IdP authenticates the user, redirects back to redirect_uri with code + state.
• SP exchanges the code at /token for an id_token (JWT containing the user's identity claims), access_token, optionally refresh_token. Uses client_secret + code_verifier (PKCE) for proof.
• SP validates the id_token signature against the IdP's JWKS, validates iss / aud / exp / nonce, creates a local session.

OIDC is lighter, JSON-based, mobile-friendly, REST-friendly. SAML remains widespread in legacy enterprise contexts.

Identity assertions carry attributes (SAML) / claims (OIDC) used to populate the SP's user record:

• Subject — unique stable ID for the user (SAML NameID, OIDC sub). Never use the email address as the subject — emails change.
• Email, given_name, family_name — display + contact attributes.
• Groups / roles — used by the SP to map to internal authorisation (after SCIM provisioning, ideally).
• Custom claims — site code, department, GxP-trained flag, supervisor — driven by the customer's HR / IdP integration.

SSO solves authentication; SCIM (RFC 7644) solves account lifecycle. The IdP becomes the source of truth and pushes user-account create / update / disable events to the SP via /Users and /Groups REST endpoints. Without SCIM, accounts are typically just-in-time provisioned at first SSO login but never disabled — a leaver retains a valid SP account until manual cleanup. SCIM is the leaver-control mechanism enterprise auditors expect.

MFA is enforced at the IdP, not the SP. The SP can require a recent / high-assurance authentication via:

• SAML — RequestedAuthnContext on the AuthnRequest (e.g. requiring AuthnContextClassRef of MultiFactor).
• OIDC — acr_values parameter on the authorisation request; the id_token contains acr + amr claims showing how authentication happened.

Critical actions — e-signature on a regulated record, batch release, recipe approval — should trigger step-up to a recent MFA session (e.g. within 15 minutes). Reusing a 9-hour-old SSO session for a 21 CFR 211.186 e-signature is a Part 11 weakness.

• Using email as the SAML NameID — when the user marries / changes name / domain, the SP creates a duplicate account.
• No SCIM — leavers retain SP access for weeks or months.
• IdP-initiated SAML enabled without RelayState validation — CSRF exposure.
• Signature verification disabled "for testing" and never re-enabled — anyone can forge an assertion.
• Clock skew tolerance set too wide (>5 min) — relays NotBefore / NotOnOrAfter into uselessness.
• Step-up MFA not enforced on e-signature events — Part 11 11.200 requires biometric or two distinct identification components for re-authentication.
• Group-based authorisation tied directly to IdP group names — IdP rename breaks SP access; better to map groups → roles in the SP.
• No break-glass local account — IdP outage locks every administrator out simultaneously.