Module 10 Lesson 3 of 6 🕑 ~35 min

> cat module-10-3-sso-federation.md

SSO & Federation

Module 9 covered SAML and OIDC as protocols. This lesson looks at the same ideas from the IAM side: what SSO buys an organisation, what it risks, and how federation trust actually gets established and kept alive between two companies' identity systems.

1 Single Sign-On

SSO lets users authenticate once and reach multiple applications without repeatedly entering credentials. An employee using Microsoft 365, Salesforce, ServiceNow, Workday, GitHub, Zoom and Slack without SSO needs 7 usernames, 7 passwords, and 7 separate authentication systems. With SSO:

User → Corporate Identity Provider → MFA
   → Authenticated Session → Multiple Applications

Concretely: Alice opens Salesforce, isn't authenticated, gets redirected to Entra ID, completes authentication + MFA, receives an identity token/assertion, and lands back in Salesforce. If she then opens another federated application, she may not need to authenticate again at all — an IdP session already exists.

Benefits

Better user experience
Fewer passwords to remember.
Centralised authentication & MFA
Security policy enforced through one central IdP; applications rely on corporate MFA instead of each rolling their own.
Faster disabling
Disabling the central identity can cut off access to many applications at once.
Better monitoring
Authentication events get logged centrally instead of scattered across every app.

SSO security risk

SSO concentrates identity security in one place. If an attacker compromises the central identity provider session, they may reach many applications at once — which is exactly why organisations have to protect the IdP itself especially carefully: MFA, phishing-resistant authentication, Conditional Access, device compliance, session controls, risk-based authentication, and tight privileged-administration controls over the IdP. SSO reduces password sprawl, but it raises the stakes on protecting one central point dramatically.

2 Federation

Federation lets separate security domains or organisations establish trust between their identity systems. If Company A uses Entra ID and a SaaS application is run by Company B, Company B doesn't need to maintain a separate password for every Company A employee — it can simply trust authentication performed by Company A instead:

User → Service Provider → "Authenticate" → Identity Provider
   → User authentication → Signed identity information
   → Service Provider → Access Granted

The organisations establish this trust relationship deliberately, ahead of time — it doesn't happen automatically.

Common federation technologies

SAML 2.0
Very common for enterprise web SSO (Module 9, Lesson 4).
OpenID Connect
Common for modern web and mobile applications (Module 9, Lesson 3).
OAuth 2.x
Primarily delegated authorisation and API access, not authentication itself.
WS-Federation
Still encountered in older Microsoft environments.
Active Directory Federation Services (AD FS)
Historically very common for federating on-premises Microsoft identities with external services. Many organisations have shifted much of this to cloud identity providers like Entra ID, but AD FS remains present in legacy environments.

Federation vs SSO

These are related but not the same thing. SSO describes the user experience — authenticate once, access multiple applications. Federation describes a trust relationship — one security domain trusts identity information issued by another. Federation technology is commonly what's used to provide SSO, but you can have SSO within a single organisation without any federation at all (just one company's own IdP and its own applications).

Federation flow with an animated assertion travelling from an external Identity Provider to a Service Provider that trusts it User Salesforce (Service Provider) Entra ID (Identity Provider) Session Created 1. Open app 2. Redirect + MFA 3. Signed assertion

Salesforce (SP) trusts Entra ID (IdP) because that trust was explicitly configured beforehand — not because federation "just works" between any two systems.

Federation metadata & signing certificates

Federated systems exchange configuration — entity identifiers, endpoints, certificates, signing information, supported bindings, logout endpoints — often as SAML metadata XML. The IdP signs assertions or tokens; the SP verifies the signature to confirm the information genuinely came from the trusted IdP. This is why certificate expiry is a real federation incident, not just a hypothetical: an expired SAML signing certificate means the application starts rejecting every SAML assertion, and potentially thousands of employees can't log in at once. Certificate lifecycle management is a genuine, recurring IAM operational responsibility, not a one-time setup task.

Claims and attributes

The IdP can send information about the user — name, email, employee ID, department, groups, role, country — generally called claims or attributes depending on the protocol. Applications make authorisation decisions based on them, e.g. department = Finance → grant Finance Dashboard. Poor claim mapping (the wrong attribute sent, or sent in the wrong format) is a very common cause of SSO logins that "succeed" but land the user somewhere with no permissions.

Lab Lab – Trace an SSO Login

🦡 Hands-on lab

Configure a test application against an identity provider (many offer free developer tiers). Log in and watch:

Browser → Application → Redirect
   → Identity Provider → Authentication
   → Token/assertion → Application

🔮 Predict first

Using browser dev tools, predict which domain you'll be redirected to, and what you expect to see in the callback URL once authentication completes. Then verify.

Reveal what to look for

You should see a redirect to the IdP's own domain (not the application's), followed by a redirect back to the application carrying either a SAML response or an authorization code/token, depending on the protocol in use. Never expose production credentials or sensitive tokens while doing this — use a test tenant.

Lesson Outcome

You should now be able to explain what SSO actually buys an organisation and what it risks, distinguish SSO (the user experience) from federation (the trust relationship), and explain why signing-certificate expiry and claim mapping are two of the most common real-world SSO failure points. Lesson 4 covers the identity lifecycle that decides when accounts like these should even exist in the first place — Joiner, Mover, Leaver.