Case Study 2: The Vendor Token That Logged In as Everyone — A Federation Misconfiguration at a University

"The attacker never broke our authentication. They were issued a valid identity by a system that trusted the wrong thing." — Incident lead, Eastfield State University (constructed)

Executive Summary

To see identity governance from the attacker's side, leave the bank for a university — a sprawling, federated environment where a single sign-on identity reaches dozens of systems and a research-computing grant pays for a third-party data platform integrated by SAML. Eastfield State University suffered a breach that involved no malware, no phishing of any user, and no exploited software vulnerability in the conventional sense. Instead, attackers exploited two ordinary identity-governance failures in combination: a stale account for a departed contractor that was never deprovisioned, and a federation misconfiguration in which a service provider failed to properly validate the SAML assertions it accepted. This case study is detection-and-analysis-heavy: rather than building a program, you will reconstruct the intrusion from telemetry, see how an attacker turns identity weaknesses into access, and identify the exact controls from this chapter that would have broken the chain. It is the mirror image of Case Study 1 — there, defenders found the orphans before an attacker did; here, an attacker found them first. All details are constructed for teaching (Tier 3), though the shape of the attack — abusing token validation and stale federated identities — reflects a real and recurring class of incident.

Skills applied: reading authentication/SAML telemetry; reconstructing an identity-based intrusion; distinguishing a credential compromise from a token/federation compromise; tracing lateral movement through federated access; mapping identity failures to specific controls (deprovisioning, assertion validation, certification, short token lifetimes).

Background

Eastfield State is a public university: roughly 30,000 students, 4,000 faculty and staff, and a long tail of researchers, contractors, teaching assistants, and affiliates who come and go every term. Its identity environment is, like every university's, gloriously complicated. A central identity provider (running on the open-source identity stack common in higher education) authenticates users and federates them via SAML to dozens of service providers: the learning-management system, the email and collaboration suite, the library's licensed databases, the HR and student-records systems, and — relevant here — a cloud-hosted research data platform that a genomics lab had procured with grant money and integrated into campus SSO so lab members could log in with their university credentials.

Two governance weaknesses sat quietly in this environment, each individually common, together catastrophic:

1. A stale contractor identity. Eighteen months earlier, the genomics lab had hired an external bioinformatics contractor for a six-month project. The contractor was given a university affiliate account so they could access the research data platform. When the contract ended, the lab's grant administrator closed out the budget — but nobody deprovisioned the affiliate identity, because affiliate accounts at Eastfield were created by departmental request and had no authoritative system of record firing a leaver trigger. The account sat enabled, a member of the genomics-lab access group, for eighteen months. (If this sounds exactly like Meridian's CONTRACTOR_X, that is the point — it is the same failure, at a different institution, in a different sector.)

2. A federation misconfiguration. The research data platform — a smaller vendor, integrated in a hurry by a lab without security review — had a dangerously permissive SAML configuration. To "make integration easier," its assertion-consumer endpoint did not strictly verify the identity provider's signature on every assertion, did not enforce the audience restriction, and accepted assertions with a generous validity window. In effect, the platform trusted SAML assertions far more loosely than it should have — the §18.3 nightmare, where the service provider accepts the XML without truly validating it.

🔗 Connection: Each weakness maps directly to a control this chapter taught. The stale affiliate account is an orphaned account (§18.5) produced by a missing leaver trigger in the JML lifecycle (§18.4) — the identical root cause as Meridian's contractor, because affiliates, like contractors, lived outside any authoritative system of record. The platform's loose assertion handling is a failure of the SAML validation checklist (§18.3): verify the signature, enforce the audience, honor the short expiry. The breach is what happens when both fail at once.

The Intrusion, Reconstructed

The university's security team reconstructed the incident after the research data platform's vendor reported anomalous data access. The reconstruction below is assembled from identity-provider logs, the platform's access logs, and the SAML exchange records — and it is a clinic in how identity weaknesses, not exploits, drive modern breaches. (All IPs are documentation ranges.)

Phase 1 — Initial access via the stale account

The attacker did not need to phish anyone. The contractor's affiliate credentials had appeared in a third-party breach dump — the contractor had reused the password elsewhere, that other service was breached, and the credential pair (username + password) ended up in a leaked-credential database the attacker purchased. Because the affiliate account was still enabled eighteen months after the contract ended, the leaked credential still worked.

IdP authentication log (illustrative)
2026-05-02 03:41:12  user=ext_bioinf_07  src=203.0.113.51  result=SUCCESS  mfa=NONE
                                                                            affiliate=genomics-lab
  Note: ext_bioinf_07 = contractor affiliate, contract ended 18 months ago,
        account never deprovisioned, NO MFA required for affiliate accounts.

Two facts in that single log line are the breach. First, result=SUCCESS for an account that should not exist — the orphaned-account failure. Second, mfa=NONE — affiliate accounts had been exempted from MFA "for convenience," so the leaked password alone was sufficient. Had either been different — had the account been deprovisioned, or had phishing-resistant MFA been required (Chapter 16) — the leaked password would have been worthless.

🛡️ Defender's Lens: This is the canonical anatomy of an identity-based breach, and it is worth memorizing because you will see it again and again in Part V. The attacker's "exploit" was a valid login. There is no malware to detect, no payload, no signature — the authentication succeeded, which is exactly why orphaned accounts are so dangerous (§18.5): they defeat the front door by being legitimate. The detection opportunity is not "block the malware"; it is behavioral — a dormant account springing to life, a login from an unusual source, an affiliate account suddenly active eighteen months after its last use. Good identity governance makes such accounts rare, which makes the behavioral detection tractable.

Phase 2 — From one account to many: abusing the federation trust

A single stale account with access to one genomics group is a contained problem. What turned it into a broad breach was the second weakness — the research platform's loose SAML validation — which the attacker discovered once inside and used to escalate from "one affiliate's access" to "any user's access."

Having authenticated as the contractor, the attacker reached the research data platform via SSO and studied how it consumed SAML assertions. They found that the platform did not verify the IdP's signature or enforce the audience restriction. That meant the platform would accept an assertion it should have rejected — and an attacker who could craft or manipulate an assertion's contents could make the platform believe they were a different, higher-privileged user (a lab principal investigator with access to far more datasets), because the platform was trusting the assertion's claims without cryptographically verifying they came unaltered from the real IdP.

Research-platform access log (illustrative) — the escalation
03:58:20  SAML assertion accepted  subject=ext_bioinf_07@eastfield.example   sig_verified=NO
04:12:33  SAML assertion accepted  subject=pi_genomics_lead@eastfield.example sig_verified=NO  audience=ANY
04:13:01  data export  user=pi_genomics_lead  dataset=human-genomic-cohort-2025  rows=2,400,000

The jump from ext_bioinf_07 to pi_genomics_lead between 03:58 and 04:12, with sig_verified=NO and audience=ANY on both, is the federation misconfiguration being exploited. A correctly configured service provider would have rejected the second assertion outright — the signature would not have verified against the real IdP's public key, because the real IdP never issued it. Instead, the platform took the assertion's word for who the user was, and handed the attacker a 2.4-million-row export of a human genomic research cohort under a principal investigator's identity.

⚠️ Common Pitfall: "We use SSO, so we're secure." SSO and federation are only as strong as the service provider's validation of the tokens it accepts. A platform that accepts unsigned or audience-unrestricted assertions has effectively disabled the cryptography that makes federation safe — it trusts the XML, not the IdP. This is why the §18.3 checklist is non-negotiable when you integrate or select an SSO'd application: require signed assertions, verify the signature against the IdP's key, enforce the audience, and keep the validity window short. The university's central IdP was fine; the small vendor's SP was the hole, and the SP is where the trust is actually enforced.

Why the validation failure is so dangerous — a defender's understanding. It is worth being precise about what the platform got wrong, because the entire class of "SAML signature bypass" vulnerabilities turns on a few specific failures, and a defender who can name them can audit for them. A SAML assertion is an XML document with a digital signature over part of it; the security guarantee is that the service provider recomputes and checks that signature against the identity provider's known public key and rejects anything that does not match. The failures that break this guarantee, all present or possible at Eastfield, are mundane and recurring:

1. Not checking the signature at all (verify_idp_signature: false). The SP reads the assertion's claims and trusts them without verifying the IdP signed them — so any well-formed XML is accepted. This is the most basic and most catastrophic failure, and it is exactly what let the attacker swap ext_bioinf_07 for pi_genomics_lead.
2. Accepting unsigned assertions (require_signed_assertions: false). Even if the SP would verify a signature, allowing an unsigned assertion through means an attacker simply omits the signature.
3. Not enforcing the audience. Even a properly signed assertion meant for a different application is accepted, so an assertion captured elsewhere is replayable here.
4. A generous validity window. A captured assertion stays usable long enough to be replayed at leisure rather than expiring in minutes.

The defender's takeaway is that none of this requires understanding exotic XML-canonicalization attacks (though those exist, and are why you use a maintained library rather than parsing signatures yourself). The audit questions are simple and you can ask them of any SSO'd application before you trust it: Does it require a signature? Does it verify that signature against the real IdP's key? Does it reject assertions addressed to other audiences? Do assertions expire quickly? Four yes-or-no questions stand between a safe integration and the Eastfield breach. The genomics lab, procuring a platform without security review, asked none of them.

Phase 3 — Why it ran undetected

The intrusion ran for several hours before the vendor's own anomaly detection flagged the unusually large export. It went undetected at the university longer than it should have for reasons that are themselves governance lessons:

• No monitoring of the stale account. Nobody was watching ext_bioinf_07, because as far as the university's mental model was concerned, that person had left eighteen months ago. An account nobody believes is in use generates no scrutiny when it is used — the §18.5 "unmonitored" property in action.
• The platform's logs were not centralized. The research data platform was a departmental procurement that never fed its logs to the university SOC (a Part V failure — Chapter 21). The signature-verification failures were visible in the platform's own logs but invisible to the people who could have acted.
• Affiliate accounts were a blind spot by design. Created by departmental request, exempt from MFA, governed by no lifecycle — the entire affiliate population was outside the identity program, which is exactly where the breach lived.

Phase 4 — Containment and the controls that would have broken the chain

Once alerted, the university's response was identity-centric: disable the stale account at the authoritative source, revoke active sessions and tokens, force the vendor to correct its SAML configuration (require and verify signatures, enforce audience, shorten the window) before re-enabling the integration, and — the strategic fix — bring the affiliate population into a real identity lifecycle. The forensic and legal handling (a breach of human genomic research data carries serious regulatory weight) followed the patterns of Chapters 24 and 25, but the preventable failures were all identity governance.

Map the breach against this chapter's controls, and notice that any one of them would have broken the chain — the essence of defense in depth:

ATTACK STEP                          CONTROL THAT WOULD HAVE BROKEN IT          (Section)
-----------------------------------  ----------------------------------------   ---------
Stale affiliate account still works  Deprovision on leaver trigger; account     §18.4
                                     expiration date; access certification       §18.5
Leaked password alone authenticates  Phishing-resistant MFA on the IdP login    Ch.16
SP accepts forged/altered assertion  Verify IdP signature on every assertion    §18.3
Assertion replayed to wrong audience Enforce audience restriction               §18.3
Escalation runs for hours unseen     Centralize SP logs to the SOC; monitor     Ch.21,
                                     dormant-account reactivation                §18.5

🚪 Threshold Concept: A breach is rarely a single failure; it is a chain of ordinary weaknesses that line up. Eastfield's attacker needed the stale account and the missing MFA and the loose assertion validation and the absent monitoring — break any link and the breach does not happen. This is why defenders invest in depth rather than perfection at one layer: you do not have to be flawless everywhere, you have to ensure the weaknesses never all align. Identity governance removes whole categories of links — every orphan you kill and every assertion you properly validate is a link the attacker no longer has.

Phase 5 — Building the detections that would have caught it next time

Prevention removes the weaknesses; detection catches the attacker who finds a weakness you missed. Because identity-based intrusions involve no malware signature, the detections are behavioral — they describe what is unusual about an identity's behavior, not what is malicious about a file. The university's SOC (the kind of capability built in Part V, Chapters 21–22) developed a set of identity detections directly from this incident, and they are worth studying as a model because every one of them is a question good identity governance makes answerable:

DETECTION                              FIRES ON                              SIGNAL FROM THIS BREACH
-------------------------------------  ------------------------------------  -----------------------
Dormant-account reactivation           account with no login in 90+ days     ext_bioinf_07 logs in
                                       suddenly authenticates                after 18 months silent
Affiliate/contractor login w/o MFA     a reduced-assurance account           mfa=NONE on a sensitive
                                       authenticates to a sensitive app      research platform
Impossible / unusual source            login from a geo/IP never seen        unfamiliar src in the
                                       for this identity                     authentication log
Assertion accepted without signature   an SP reports sig_verified=NO         the platform's own logs
  verification (if SP logs reach SOC)                                        showed it the whole time
Identity-jump on one platform          two different high-value subjects     ext_bioinf_07 then
                                       from one session/source in minutes    pi_genomics_lead in 14 min
Bulk data export anomaly               export volume far above an            2.4M-row cohort export
                                       identity's historical baseline        (the vendor's own alert)

Notice that several of these detections were possible from data the university already had — the dormant-account reactivation, the no-MFA affiliate login, and the unusual source were all sitting in the identity provider's own logs. What was missing was not the data but the will to centralize and watch it: the IdP logs were not feeding a SIEM with these rules running. The single most damning entry is sig_verified=NO — the research platform was logging its own failure to verify signatures the entire time, but because that platform's logs never reached anyone who could act, the most direct possible alarm rang in an empty room.

🛡️ Defender's Lens: Good identity governance and good detection are the same investment viewed from two angles. Governance reduces the base rate of anomalous identity events (few orphans, few dormant accounts, no MFA-exempt populations), and a low base rate is exactly what makes behavioral detection work — "a dormant account just woke up" is a high-fidelity alert only if dormant accounts are rare and tracked. In an environment swimming in orphans and stale accounts, the same alert drowns in noise. This is the deep reason the two halves of this chapter — the lifecycle (§18.4) and the review/hunt (§18.5) — are not just compliance hygiene: they are what make the SOC's identity detections tractable. Clean up the identities, and the anomalies that remain are worth alerting on.

Phase 6 — The institutional fix

Eastfield's lasting remediation went beyond the immediate incident, because the team understood that the stale affiliate account was a symptom of a population that lived outside the identity program entirely. The durable fixes mirrored Meridian's, adapted to a university:

• An authoritative system of record for every population — not just employees (HR) and students (the registrar), but the long tail of affiliates, contractors, visiting researchers, and emeriti who had previously been created by ad-hoc departmental request. Each population now has an owner and a record with a mandatory end/review date that fires a leaver trigger.
• No standing MFA exemptions. The affiliate carve-out was eliminated; phishing-resistant MFA became the baseline for any account touching sensitive systems, with narrow, time-boxed, individually-approved exceptions rather than a blanket population exemption.
• An identity-integration review for SSO'd applications (the kind of control Chapter 29's third-party risk process formalizes), so that no future vendor integration goes live with the loose assertion validation that let the escalation happen. Signature verification, audience enforcement, and short token lifetimes became pass/fail gate items for any SAML or OIDC integration.
• Centralized identity logging. Departmental applications that authenticate via campus SSO must now feed their access logs to the SOC, closing the blind spot that hid the sig_verified=NO events.

The Same Failure, Two Sectors

The most useful thing about studying Eastfield right after Meridian is that they are the same breach precondition in two very different organizations, and the comparison isolates what is universal about identity governance from what is merely contextual. Place them side by side:

Two lessons fall out of the comparison. First, the root cause is sector-independent: any organization that lets some population of people be created and granted access outside an authoritative system of record will accumulate orphaned accounts, full stop — banks call them contractors, universities call them affiliates, hospitals call them locums and rotating residents, and the mechanism is identical. The minimum viable fix is identical too: give every population an authoritative record with a mandatory end date that fires a leaver trigger, and a fail-safe account expiration beneath it. Second, the difference in outcome — a clean remediation at Meridian versus a data breach at Eastfield — was determined not by the root cause (which both shared) but by everything layered on top: whether MFA would have blunted the leaked credential, whether the downstream application validated its tokens, and whether anyone was watching. Meridian had done the Chapter 16 MFA work and ran the review; Eastfield had an MFA exemption, an un-vetted integration, and no monitoring. Same hole in the floor; one organization had a net under it and the other did not.

🔗 Connection: This is the recurring asymmetry of Theme 2 made concrete across two organizations. The attacker needs the chain to complete once; the defender needs to break it anywhere. Meridian broke it in several places (MFA, certification) and never even reached the exploitation stage; Eastfield had every link intact and lost the data. Identity governance is the discipline of ensuring that the link you don't know about is not the only thing standing between an attacker and your crown jewels — which is why you build depth, and why you assume some orphan, somewhere, is waiting to be found.

Discussion Questions

1. The attacker's "exploit" was a valid login followed by an accepted assertion — no malware, no software vulnerability in the usual sense. How does this change the way you would detect such an intrusion compared with, say, a ransomware infection? What telemetry matters most?
2. The research data platform's loose SAML validation was chosen "to make integration easier." Whose responsibility was it to catch this — the vendor, the genomics lab, or the central security team — and what process (touched on in Chapter 29's third-party risk) would have surfaced it before integration?
3. Eastfield exempted affiliate accounts from MFA "for convenience." Argue both sides: when, if ever, is a reduced-assurance population defensible, and what compensating controls would you demand if you allowed it?
4. The same root cause — a population (contractors/affiliates) outside any authoritative system of record — produced an orphaned account at both Meridian (Case Study 1) and Eastfield. Why is this population such a persistent, cross-sector blind spot, and what is the minimum viable fix that works for a bank, a university, and a small business?
5. At Eastfield the orphan was found by an attacker; at Meridian it was found by an access review. List the specific governance practices that determine which of those two outcomes an organization gets.

Your Turn

You are handed an SSO'd application your organization is about to adopt (pick a real category: a SaaS HR tool, a research platform, a marketing system). Write a one-page identity integration review the application must pass before approval, derived entirely from this case study's failures. Cover at minimum: the authentication protocol and how the SP validates assertions/tokens (the §18.3 checklist as explicit pass/fail items), how accounts are provisioned and — critically — deprovisioned (is SCIM supported?), whether any user population would be exempt from MFA and why that is or is not acceptable, and whether the application's logs will reach your SOC. Then write the single sentence you would put at the top of the review: "This integration is safe only if ______." Make it the thing that, if false, sinks the whole approval.

Key Takeaways

• Identity-based breaches often involve no malware and no classic exploit — just a valid login and an accepted token. The attacker's "exploit" is legitimacy, which is why orphaned accounts (§18.5) are so dangerous and why detection must be behavioral (dormant account reactivation, unusual source).
• Federation is only as strong as the service provider's validation. "We use SSO" guarantees nothing if the SP accepts unsigned or audience-unrestricted assertions; the §18.3 checklist — verify the signature, enforce the audience, honor the short expiry — is where federation's safety actually lives.
• A populations-without-a-system-of-record blind spot recurs across sectors. Contractors at a bank, affiliates at a university — the same missing leaver trigger produces the same orphaned account. The minimum viable fix is an authoritative roster plus a mandatory account-expiration date.
• Breaches are chains of ordinary weaknesses. Eastfield needed a stale account and missing MFA and loose assertion validation and absent monitoring; breaking any one link stops it. Defense in depth, and the identity governance that removes whole categories of links, is the answer to attacker asymmetry.
• Who finds the orphan determines everything. The difference between Meridian (found by a review) and Eastfield (found by an attacker) is precisely the presence of deprovisioning automation, access certification, MFA, and centralized monitoring — the practices of this chapter.