SSO / SAMLSingle Sign-On / Security Assertion Markup Language
Single Sign-On (SSO) federates user authentication from an enterprise identity provider (IdP) — Okta, Entra ID (Azure AD), Ping, Google Workspace, OneLogin, JumpCloud — into a service provider (SP) so the user signs in once at the IdP and is trusted by the SP.
Read the full summary
SAML 2.0 is the long-established XML protocol; OpenID Connect (OIDC) is the modern JSON / OAuth 2.0 successor. For regulated-manufacturing SaaS, SSO is a security baseline expectation, plus an explicit 21 CFR Part 11 control (unique user identification and authentication, 11.10(d)) and a SOC 2 Common Criteria CC6 control.
On this page · 8 sections
How does SSO / SAML apply to your shop floor?
Pick your industry and scale — Ask V5 rewrites the definition in your context, gives a worked example, and shows what V5 does on day one.
01What SSO is (and isn't)
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.
02SAML 2.0 flow
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.
03OIDC flow
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.
04Attributes and claims
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.
05SCIM provisioning
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.
06MFA and step-up authentication
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.
07Common mistakes
- 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.
08How V5 Ultimate handles SSO
Frequently asked questions
Q.SAML or OIDC — which should we use?+
OIDC if the IdP supports it for your application catalog — lighter, JSON, mobile-friendly. SAML if your IdP integration tooling only supports SAML. Both are equivalent in security posture when configured correctly.
Q.Does SSO replace user accounts in V5?+
No — V5 still holds a local user record (for RBAC, e-signature attribution, training records). SSO replaces the password / MFA prompt; the user record continues to exist and SCIM keeps it in sync.
Q.Is SSO enough for 21 CFR Part 11?+
Authentication-wise it satisfies the 11.10(d) unique-user requirement, and step-up MFA satisfies 11.200 for e-signatures. Part 11 also requires audit trail, training records, e-signature meaning attribution and many other controls — SSO is one piece.
Q.What happens if the IdP goes down?+
Users cannot SSO until the IdP recovers. V5 retains a break-glass local owner account so administrative recovery actions remain available. Critical workflows (batch release) wait for IdP recovery — by design, Part 11 prefers a halted workflow to an un-authenticated signature.
Q.Does V5 support multiple IdPs simultaneously?+
Yes on the Enterprise plan — typical scenario is one IdP for employees + one for contract operators / contract-manufacturing partners, with separate role mappings per IdP.
Primary sources
Further reading
- RBACAuthorisation that runs after SSO authentication completes.
- 21 CFR Part 11The GxP electronic-signature regime SSO supports.
- SOC 2CC6 access-control criteria SSO directly satisfies.
- Audit trailEvery SSO event lands as an immutable audit record.
- Two-person e-signatureSSO authenticates the identity used in the e-signature.
Explore this topic
SSO / SAML sits inside 2 overlapping topic clusters in our glossary. Every neighbour is one click away.
Electronic records, signatures, audit trail and ALCOA+ data-integrity principles.
Where each shop-floor system fits and what it owns vs the ERP above it.
Want to see how SSO / SAML could fit into your own records and workflows? Explore the related V5 pages or talk to our team about what applies to your operation.