Module 09 Lesson 4 of 6 🕑 ~40 min

> cat module-09-4-saml-federation.md

SAML & Federation

SAML predates OAuth and OpenID Connect, and it's still running an enormous share of enterprise Single Sign-On. This lesson covers how it works, what federation actually means, and when you'll meet SAML instead of OIDC in the real world.

1 Authentication vs Federation

Authentication proves identity. Federation lets one organisation or security domain rely on authentication performed somewhere else entirely:

Company A employee
        ↓
Company A Identity Provider
        ↓
SAML/OIDC federation
        ↓
Company B application

Company B doesn't necessarily maintain a separate password for the user — it trusts Company A's identity provider instead. Federation is extremely common in SaaS, B2B portals, partner access, contractor access, and cloud environments.

SAML (Security Assertion Markup Language) has been the workhorse of enterprise federation and Single Sign-On for two decades, and remains extremely common in large organisations, even as OpenID Connect (Lesson 3) takes over for newer web and mobile applications.

Identity Provider — IdP
Authenticates the user (e.g. a corporate identity platform).
Service Provider — SP
The application the user wants to access — e.g. an HR application, expense system, CRM, or ticketing platform.

2 SAML Authentication Flow

A simplified service-provider-initiated SAML flow:

SAML service-provider-initiated login flow with an animated assertion travelling from Identity Provider to Service Provider User Service Provider (SP) Identity Provider (IdP) Session 1. Open app 2. Redirect 3. Authenticate 4. Signed assertion 5. Session created

1–3: the SP redirects the user to the IdP to authenticate. 4: the IdP returns a signed SAML assertion. 5: the SP validates it and creates a session.

User → Service Provider → Redirect to IdP
   → Identity Provider authenticates user
   → SAML Response (signed SAML Assertion) → Service Provider
   → Service Provider validates assertion → Session created

3 SAML Assertions & Metadata

SAML assertions

An assertion can carry information such as user identity, email, name, groups, roles, authentication time, and authentication method. SAML typically uses XML, and its security depends heavily on correct handling of digital signatures, certificates, audience restrictions, recipient validation, assertion lifetime, and XML processing — a lot of surface area for something to go subtly wrong.

SAML metadata

SAML integrations exchange metadata containing entity IDs, SSO endpoints, certificates, and binding information. Large companies frequently maintain hundreds or thousands of federation relationships — which makes certificate expiration a real operational concern. A certificate change that isn't coordinated between the IdP and SP can break SSO for an entire application, sometimes for every employee at once.

4 SAML vs OpenID Connect

Both provide federated authentication. A simplified enterprise comparison:

SAMLOpenID Connect
XML basedJSON/HTTP oriented
Older enterprise federation technologyModern web/mobile identity technology
Common in enterprise SaaSCommon in modern applications and APIs
Uses assertionsUses ID tokens
Strong legacy enterprise presenceStrong modern development presence

Neither technology is simply "good" or "bad" — the important question is whether it's implemented securely and appropriately for the application in front of you.

Lab Lab – Inspect a SAML Flow

🦡 Hands-on lab

Using a lab identity provider and service provider (several vendors offer free developer/trial tiers that support SAML), walk through a login and locate: Service Provider, Identity Provider, SAML Request, SAML Response, SAML Assertion, user attributes, and certificate.

🔮 Find these in the assertion

Issuer, Audience, NameID, authentication time, and the signing certificate.

Reveal the point of the exercise

The goal isn't to memorise XML syntax — it's to understand the trust relationship: the SP is trusting a signed statement from the IdP that says "this user authenticated, here's who they are." Everything else in the exercise (issuer, audience, NameID, signature) exists to make that trust verifiable rather than blind.

Lesson Outcome

You should now be able to explain the SP/IdP relationship, walk through a SAML login flow, describe what a SAML assertion and SAML metadata contain, and compare SAML against OpenID Connect. Lesson 5 moves from federated web SSO to the authentication protocols running inside the corporate network itself: Kerberos, NTLM, and LDAP.