Episode 22 · Module 5 · Authentication

SSO, SAML and Enterprise Identity

19 May 2026 · 9:02 · Security for Legal SaaS

9:02 9:02

When a 200-lawyer firm evaluates your legal SaaS platform, Single Sign-On is rarely optional. SSO — the ability to log in once through the firm's own identity provider and gain access to every connected application — is a security requirement, not a convenience feature. And from a vendor's perspective, saying yes to SSO is one of the smartest security decisions you can make, because it shifts authentication management to the client's own IT team.

Today’s Lesson

Security for Legal SaaS — Episode 22: SSO, SAML and Enterprise Identity

Why Enterprise Clients Demand SSO

In Episode 20, we covered OAuth 2.0 and OpenID Connect — the protocols that power consumer-facing "Sign in with Google" flows. Enterprise SSO builds on those concepts but uses a different set of protocols and a fundamentally different trust model. Where OAuth delegates access, enterprise SSO federates identity: the client's directory becomes the authoritative source of who works there, what access they should have, and — critically — when they should lose it.

SAML: The Enterprise Standard

Security Assertion Markup Language (SAML) — an XML-based open standard first published in 2002 and revised as SAML 2.0 in 2005 — remains the dominant SSO protocol in enterprise legal tech.¹ It works through a three-party trust model:

Component	Role	Legal SaaS Example
Identity Provider (IdP)	Authenticates users and issues identity assertions	The law firm's Azure AD, Okta, or PingFederate instance
Service Provider (SP)	Your application — receives and validates assertions	Your case management or document review platform
Principal	The user seeking access	A partner, associate, or paralegal at the firm

The SSO Flow

In a Service Provider-initiated (SP-initiated) flow — the most common pattern — the user navigates to your application, which redirects them to their firm's IdP. The user authenticates there (using whatever MFA the firm enforces, as we discussed in Episode 21), and the IdP sends a signed XML document called a SAML assertion back to your application. This assertion contains the user's identity attributes: email address, name, group memberships, and any custom attributes the firm chooses to share.²

In an IdP-initiated flow, the user starts at the firm's identity portal and clicks your application's icon. This skips the initial redirect but introduces a security consideration: without an SP-generated authentication request to bind to, IdP-initiated flows are more vulnerable to replay attacks. The OWASP SAML Security Cheat Sheet recommends SP-initiated flows wherever possible.³

SAML vs. OpenID Connect

For new implementations, the industry is increasingly moving toward OpenID Connect (OIDC) — the JSON-based identity layer built on OAuth 2.0 that we covered in Episode 20. OIDC is lighter, easier to implement, and better suited to modern web and mobile architectures. But SAML is not going away:

Dimension	SAML 2.0	OpenID Connect
Data format	XML	JSON
Token type	Signed XML assertion	JWT (JSON Web Token)
Typical use	Enterprise SSO, legacy IdPs	Modern web/mobile apps, consumer SSO
Complexity	Higher (XML parsing, signature validation)	Lower (standard HTTP/JSON)
Enterprise adoption	Ubiquitous in large law firms	Growing, but SAML still required by many

Practical reality: If you're building legal SaaS for enterprise clients, you'll need to support both. Many firms still run SAML-only IdPs, and some require SAML specifically in their procurement security questionnaires.

SAML Security Vulnerabilities

SAML's XML foundation creates a distinct class of vulnerabilities that JSON-based protocols avoid entirely.

Signature wrapping attacks are the most dangerous. In March 2025, GitHub disclosed CVE-2025-25291 and CVE-2025-25292 in the ruby-saml library — vulnerabilities scoring 8.8/10 on the CVSS scale.⁴ The attack exploited differences between how two XML parsers (REXML and Nokogiri) interpreted the same document. An attacker could craft a SAML response where the signed portion contained one identity but the parsed portion contained another, allowing authentication as any user — including administrators.

Earlier, in 2024, CVE-2024-6800 affected GitHub Enterprise Server itself, allowing attackers to forge SAML responses and bypass authentication entirely.⁵ These aren't theoretical — they're production vulnerabilities in widely-used software.

The OWASP SAML Security Cheat Sheet identifies several critical mitigations:³

Validate the XML schema before verifying the signature — reject malformed documents before processing
Use secure key selectors that ignore `KeyInfo` elements from the XML message itself
Apply absolute XPath expressions for signature scope verification
Never accept `alg=none` for any cryptographic operation

SCIM: Automated User Lifecycle

SSO solves authentication — but it does not solve provisioning. When a new associate joins the firm, someone still needs to create their account in your application. When they leave, someone needs to disable it. Manual provisioning at scale is a recipe for orphaned accounts — active credentials belonging to departed employees.

SCIM (System for Cross-domain Identity Management), defined in RFC 7644, automates this lifecycle.⁶ It's a REST API standard that lets the firm's identity provider push user records directly into your application:

Provisioning: IT adds a new lawyer in Okta or Azure AD → SCIM creates their account in your application within minutes
Updates: The lawyer moves from the litigation department to M&A → SCIM updates their attributes (and your application can adjust access accordingly)
Deprovisioning: The lawyer leaves the firm → SCIM disables or deletes their account immediately

Why this matters for legal SaaS: A firm with 500 lawyers might use 30 different SaaS platforms. Without SCIM, each departure requires manual deprovisioning across all 30 systems. Miss one, and a former employee retains access to privileged client communications. SCIM eliminates this class of risk entirely.⁷

Multi-Tenant SSO: One IdP Per Tenant

In a multi-tenant legal SaaS platform — where multiple firms share the same application infrastructure — each firm needs its own SSO configuration. This is called IdP-per-tenant routing, and it typically works by email domain:

User enters their email address on your login page
Your application extracts the domain (e.g., `@bakermckenzie.com`)
A lookup table maps that domain to the firm's specific IdP configuration
The user is redirected to their firm's IdP for authentication

This means your application must maintain a separate SAML or OIDC configuration for each enterprise client — including their IdP metadata URL, certificates, and attribute mappings. A configuration error in one tenant's SSO setup must never affect another tenant's authentication. We'll cover the broader multi-tenancy isolation challenge in Episode 27.

The SSO Tax — and Why It's Worth Paying

A common criticism in the SaaS industry is the "SSO tax" — vendors charging significantly more for SSO support, effectively penalising better security practices. sso.tax maintains a public list of vendors that charge premium prices for SSO.⁸

For legal SaaS, this framing misses the point. Enterprise law firms require SSO not as a premium feature but as a baseline security control. Supporting SAML SSO signals to enterprise procurement teams that your platform is ready for their security requirements. The implementation cost is real — maintaining SAML libraries, handling IdP certificate rotations, debugging XML signature issues — but the alternative is losing enterprise deals entirely.

NIST Guidance: Federation Assurance Levels

NIST SP 800-63C defines three Federation Assurance Levels (FALs) that govern how identity assertions are protected:⁹

Level	Requirement	Legal SaaS Relevance
FAL1	Bearer assertion (signed)	Minimum for SSO — the assertion proves identity
FAL2	Holder-of-key assertion (assertion bound to a specific key or device)	Higher assurance, suitable for sensitive matters
FAL3	Holder-of-key with hardware-backed cryptographic authenticator	Maximum assurance — government, national security

Most legal SaaS platforms operate at FAL1, with signed SAML assertions over TLS (which we covered in Episode 13). Firms handling government contracts or national security matters may require FAL2, where the assertion is cryptographically bound to the user's session.¹⁰

What's Next

Episode 23 covers RBAC — Roles, Permissions and Scopes — how to structure who can do what inside your application, from firm administrator to paralegal to external client viewer.

Sources & Further Reading

Sources & references

OASIS, SAML 2.0 Standard — the XML-based identity federation standard.
NIST, SP 800-63C: Federation and Assertions — federal guidelines for identity federation.
OWASP, SAML Security Cheat Sheet — implementation guidance and common vulnerability mitigations.
GitHub Blog, Sign in as Anyone: Bypassing SAML SSO Authentication with Parser Differentials — CVE-2025-25291/25292 disclosure (March 2025).
ProjectDiscovery, GitHub Enterprise SAML Authentication Bypass (CVE-2024-6800) — SAML signature wrapping in GHES.
IETF, RFC 7644: SCIM Protocol — the standard for automated user provisioning.
SSOJet, SCIM Provisioning Best Practices — practical guidance for SCIM implementation.
sso.tax, SSO Wall of Shame — tracking vendors that charge premiums for SSO.
NIST, SP 800-63C: Federation Assurance Levels — FAL1, FAL2, FAL3 definitions.
IDManagement.gov, Enterprise Single Sign-On Playbook — federal SSO implementation guidance.
PortSwigger Research, The Fragile Lock: Novel Bypasses for SAML Authentication — advanced SAML attack techniques.
Endor Labs, CVE-2025-47949: samlify SAML SSO Bypass — signature wrapping in samlify library.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 22 — Single Sign-On, SAML, and enterprise identity. Alice, last episode we covered multi-factor authentication. This feels like the next layer — how do large firms actually manage all those logins across dozens of platforms?

Alice: That's exactly right. Imagine you're a partner at a 200-lawyer firm. You use a case management system, a document review tool, a billing platform, an e-filing system, maybe a contract analytics tool — each one with its own login. Without SSO, that's five separate passwords. Five places where your credentials could be phished. Five accounts that IT has to manually disable when someone leaves. SSO — Single Sign-On — means you log in once through your firm's own identity system, and that one login gives you access to all of them.

Dan: Right. So the firm's IT team is doing the heavy lifting on authentication, not each individual vendor?

Alice: Exactly. And that's why enterprise clients don't ask for SSO as a nice-to-have. They require it. Because it means they control the front door. They decide what MFA method to enforce — remember the passkeys and hardware keys we discussed in Episode 21 — and that policy applies everywhere. One set of rules, enforced consistently across every application their lawyers use.

Dan: Mm. So how does this actually work under the hood? I keep hearing "SAML" thrown around.

Alice: SAML — Security Assertion Markup Language — is the protocol that makes enterprise SSO work. It's been around since the early 2000s and it's still the most common SSO protocol in large organisations. Think of it like a trusted letter of introduction. The firm's identity provider — that's their system that knows who works there — is like a notary. When a lawyer tries to log into your application, your application says "I don't know you — go get a signed letter from your firm's notary." The lawyer goes to the firm's identity provider, proves who they are — password plus MFA — and the identity provider signs a document that says "this is Sarah Chen, she's a senior associate in the M&A department, and I vouch for her." That signed document is called a SAML assertion. Your application checks the signature, confirms it came from a trusted source, and lets Sarah in.

Dan: Yeah, that makes sense. So your application never sees her actual password?

Alice: Never. Your application never stores it, never transmits it, never handles it. The firm's identity provider does all of that. Which is genuinely good security design — you've removed an entire category of risk from your system. If your database gets breached, there are no password hashes to steal because you never had them.

Dan: Hmm. What about OIDC — OpenID Connect? We covered that in Episode 20. How does that fit in?

Alice: Good question. OpenID Connect is the newer, lighter-weight alternative. It's built on OAuth 2.0, uses JSON instead of XML, and it's much easier to implement. For new applications, OIDC is usually the better choice. But here's the practical reality — many large law firms still run identity providers that only speak SAML. Their Azure AD or PingFederate was configured years ago for SAML, and nobody's migrating it. So if you're building legal SaaS for enterprise clients, you'll probably need to support both.

Dan: Mm-hmm. Now, you mentioned SAML uses XML. Are there security risks specific to that?

Alice: <sigh> Yes, and they're not theoretical. In March 2025, GitHub disclosed a pair of vulnerabilities in a widely-used SAML library — ruby-saml. The attack exploited something called a parser differential. The library used two different XML parsers internally, and they interpreted the same document differently. An attacker could craft a SAML response where the signed part said "I'm a regular user," but the part the application actually read said "I'm an administrator." The signature checked out — because the signed part was technically valid — but the application granted admin access to the wrong identity. You could literally sign in as anyone.

Dan: That's alarming. How do you defend against something like that?

Alice: The OWASP SAML Security Cheat Sheet has the key guidance. First, validate the XML structure before you check the signature — reject anything malformed before processing. Second, use absolute XPath expressions when locating the signed elements, so an attacker can't move them around in the document. Third, prefer SP-initiated flows — that's where your application starts the process — because they include a request ID that binds the response to a specific login attempt. IdP-initiated flows, where the user starts from the firm's portal, are more vulnerable to replay attacks.

Dan: Right. Let me ask about something practical. SSO handles logging in. But what about when someone joins the firm or leaves?

Alice: That's provisioning and deprovisioning, and it's where a protocol called SCIM comes in. SCIM — System for Cross-domain Identity Management — is a REST API standard that connects the firm's user directory to your application. When IT adds a new associate in Okta or Azure AD, SCIM automatically creates their account in your platform. When that associate leaves the firm and IT disables their directory account, SCIM automatically disables their access to your application too. No manual steps, no delay.

Dan: Mm. And without that, someone who leaves the firm could still have active credentials?

Alice: Exactly. Those are called orphaned accounts, and they're one of the most common security gaps in enterprise environments. A firm with 500 lawyers using 30 different SaaS platforms — that's 15,000 account-application pairs. Without automated deprovisioning, every departure requires someone in IT to manually disable accounts across all 30 systems. Miss one, and a former employee — or anyone who compromises their credentials — retains access to privileged client communications.

Dan: Yeah. That connects back to the Snowflake breach we've been hearing about — stolen credentials on accounts that should have been deprovisioned.

Alice: It's exactly that pattern. The Snowflake incident in 2024 affected over 165 organisations. The attackers didn't break any encryption or exploit a zero-day. They used stolen credentials from old infostealer malware, and the accounts didn't have MFA. If those accounts had been automatically deprovisioned when employees left, or if MFA had been enforced through SSO policy, the breach wouldn't have happened.

Dan: Mm. One more thing — how does SSO work when your platform serves multiple firms? Firm A and Firm B both use your tool, but they have different identity providers.

Alice: That's multi-tenant SSO. Each firm gets its own identity provider configuration in your system. The routing usually works by email domain. A user types their email address on your login page, your application sees the domain — say, bakermckenzie.com — looks up which identity provider is mapped to that domain, and redirects the user there. The important thing is that each tenant's SSO configuration is completely isolated. A misconfiguration in Firm A's setup must never affect Firm B's authentication. We'll dig deeper into multi-tenant isolation in Episode 27.

Dan: Right. Quick summary for anyone building legal SaaS — support both SAML and OIDC, implement SCIM for automated provisioning, and prefer SP-initiated flows for SAML.

Alice: And keep your SAML libraries updated. Those parser differential attacks we discussed — they targeted real production systems. One library update is the difference between secure authentication and "sign in as anyone."

Dan: Next episode — RBAC: Roles, Permissions and Scopes. How you structure who can do what inside your application.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.