Federation, single sign-on and multifactor authentication

Why this matters

The previous lesson covered what an identity is allowed to do. This one covers how it proves who it is, and where that identity lives.

The central decision is whether cloud accounts are a second set of users or a view of the ones you already have. Creating local users in every cloud account is the intuitive choice and it is wrong: it means separate joiners and leavers processes, separate password policies, separate multifactor enrolment, and — the failure that actually bites — an employee who leaves, is removed from the corporate directory, and still has working cloud credentials nobody thought about.

Federation fixes that by making the corporate directory the single source of truth, and it is the answer to a large family of exam scenarios.

The lesson

SAML and OIDC, and what each one actually carries between the parties

Two protocols do nearly all federation, and the exam expects you to tell them apart.

SAML 2.0. XML-based, mature, and the standard for enterprise web single sign-on. Three parties: the principal (the user), the identity provider (which authenticates them), and the service provider (which they want to use). The identity provider issues a signed XML assertion stating who the user is and what attributes and group memberships they have; the service provider validates the signature and trusts it.

OpenID Connect. A thin identity layer on top of OAuth 2.0, using JSON and JWTs over HTTPS. It issues an ID token (who the user is) alongside an access token (what the bearer may do). Simpler for developers, works well for mobile and single-page applications, and it is the modern default for new systems.

The distinction people get wrong is worth stating plainly: OAuth 2.0 is an authorisation framework, not an authentication protocol. It exists to let one application access resources on a user's behalf. OpenID Connect is what adds authentication to it. A scenario asking how an application proves who the user is should not be answered with bare OAuth.

The other protocol to recognise is SCIM, which does provisioning rather than authentication — creating, updating and deactivating accounts in the target system as they change in the directory. Federation authenticates; SCIM keeps the accounts themselves in step. Together they are what makes the leaver case work end to end.

The trust relationship in all of this is established by exchanging metadata and keys, and it is what makes signature validation possible. Certificate expiry on that trust is a classic outage: the federation stops working, everybody loses access simultaneously, and the fix requires access that people have just lost.

Federating an existing directory rather than creating a second set of users

The pattern: users authenticate against the corporate identity provider, which asserts their identity to the cloud, and they assume a role (objective 4.2) with permissions mapped from their directory groups.

What it gives you:

• One source of truth. A leaver is disabled once, in the directory, and cloud access ends with it. This is the strongest argument and the one to remember.
• One set of policies — password rules, lockout, multifactor, conditional access — applied consistently.
• No long-lived cloud credentials for people. Federated sessions are short-lived by construction, which removes an entire class of credential leakage.
• Access by group membership, so joiners and movers are handled by the existing HR-driven process rather than by a separate ticket.
• One place to audit who had access to what.

Practical considerations:

• Map groups to roles deliberately. A sloppy mapping — everyone in "Engineering" to an administrative role — undoes the least-privilege work of the previous lesson.
• Keep break-glass accounts, which are the one legitimate exception below.
• Session duration is a real trade: short sessions are safer and re-authenticate more often.
• The identity provider becomes critical infrastructure. If it is down, nobody can sign in to anything — so it needs the availability treatment from objective 3.2, and it must not depend on the environment it protects.

Single sign-on, and the blast radius it concentrates in one account

Single sign-on means authenticating once and reaching many applications without signing in again.

The security case for it is strong and slightly counter-intuitive, so it is worth being explicit: SSO improves security overall because it removes dozens of separate passwords, eliminates password reuse across systems, allows one strong multifactor policy to protect everything, and — most importantly — makes deprovisioning actually work. Systems with separate local accounts are the ones a leaver retains access to.

The trade-off is concentration. One credential now opens everything, which means:

• A compromised SSO account is a compromise of every connected system. That is why multifactor on the identity provider is non-negotiable rather than a good idea.
• Session hijacking is more valuable to an attacker, so session tokens deserve protection: short lifetimes, binding to device or network where supported, and revocation that actually works.
• The identity provider is a single point of failure for availability as well as security.

The mitigations are conditional access and step-up authentication: evaluate each sign-in against device compliance, location, network and risk signals, and require additional verification for sensitive actions even within an existing session. That way one authentication does not silently authorise everything for eight hours.

MFA factors ranked honestly, and why SMS is the weakest one still in wide use

Multifactor authentication requires evidence from more than one category: something you know (password, PIN), something you have (token, phone, key), something you are (fingerprint, face). Two passwords are not multifactor; a password plus a code from an app is.

Ranked by resistance to real attacks, strongest first:

1. Hardware security keys using FIDO2/WebAuthn. Phishing-resistant by design, because the key verifies the site's origin cryptographically and simply will not authenticate to a lookalike domain. This is the only widely available factor that defeats a real-time phishing proxy, which is how most modern MFA bypass works.
2. Platform authenticators using the same standard — device biometrics backed by WebAuthn. Same protection, more convenient.
3. Push notifications with number matching. Good, and plain push without number matching is vulnerable to MFA fatigue, where an attacker sends repeated prompts until someone approves one to make it stop.
4. Time-based one-time codes from an authenticator app. Solid against password-only attacks, phishable — the user can be induced to type the code into a fake site.
5. SMS codes. The weakest still in wide use: vulnerable to SIM swapping, to interception, and to the same phishing as any typed code. Standards bodies have discouraged it for years.

The honest position: SMS is far better than nothing and is often what gets broad adoption, so it is a reasonable baseline and a poor destination. Require phishing-resistant factors for privileged access, where the value justifies the friction.

Two related ideas the exam may touch: passwordless authentication, which replaces the password with a strong possession factor rather than adding to it; and risk-based / adaptive authentication, which asks for more evidence when the context looks unusual — a new device, an unfamiliar country, an impossible travel pattern. That last signal reappears as a detection in objective 6.3.

Break-glass accounts, their controls, and the audit that watches them

Federation creates a dependency: if the identity provider is unavailable — an outage, an expired certificate, a misconfiguration — nobody can sign in, and the people who could fix it cannot get in either.

Break-glass accounts are the deliberate exception. A small number of local accounts that do not depend on federation, held for emergencies.

They are dangerous by nature, so they carry specific controls:

• Cloud-native, not federated, which is the entire point.
• Very few — typically two, so one being unavailable is not a lockout.
• Long, random, unique credentials, split or stored so that no single person can use one alone where the environment justifies it.
• Hardware multifactor, stored securely and physically separately.
• No API keys, console access only.
• Stored outside the environment they recover — the same rule as the DR runbook in objective 3.2, and for the same reason. Credentials kept only in a password manager that itself uses SSO are not break-glass credentials.
• Alert on every use, to multiple people, immediately. These accounts should be used essentially never, so any use is either an emergency or an incident, and both warrant an immediate look.
• Tested periodically — an untested break-glass account is an assumption, and this is the same lesson as the restore test. Test, then rotate the credential.
• Documented: who may use them, under what circumstances, with what approval, and what must be recorded afterwards.

The audit trail is what makes them acceptable. A privileged account nobody watches is a risk; a privileged account whose every use generates an immediate, investigated alert is a control.

What to take into the exam

• SAML = XML assertions, enterprise web SSO. OIDC = JSON/JWT on top of OAuth 2.0. OAuth alone is authorisation, not authentication. SCIM provisions accounts, it does not authenticate.
• Federate rather than creating local users — the decisive reason is that a leaver is disabled once and cloud access ends with it.
• The identity provider becomes critical infrastructure, and its trust certificate expiring locks everyone out at once.
• SSO concentrates blast radius; mitigate with conditional access and step-up authentication.
• MFA ranking: FIDO2/WebAuthn keys (phishing-resistant) > platform authenticators > push with number matching > TOTP > SMS. Plain push invites MFA fatigue; SMS is vulnerable to SIM swapping.
• Break-glass accounts are non-federated, few, hardware-MFA protected, stored outside the environment, alerted on every use, and tested.