The Evolution of Federated Access: Moving Beyond the Bilateral Trap

At its most basic level, identity management is about answering a simple question: Who are you, and what are you allowed to do? But as organizations grow, cross boundaries, and collaborate globally, answering that question becomes a monumental architectural challenge. In this post, we’ll trace the evolutionary path of modern access control—moving from localized credentialing to single sign-on, and ultimately examining the massive philosophical chasm between fragile bilateral federations and scalable, trusted multilateral federations.

1. The Localized Resource & The “Pocket Notebook” Era

Let’s start with the most basic public web resource: a simple corporate or organizational landing page. Initially, it stands up on an Apache web server with some basic HTML. It works perfectly fine—until you scale.

As an organization grows, so do its content needs. You add a wiki for internal documentation. You implement a Content Management System (CMS) to allow multiple communications team members to manage public content. Suddenly, a simple local .htpasswd file or an uncoordinated collection of FTP, CMS, and wiki accounts is no longer scalable or secure.

We’ve all been there. Two decades ago, I was working within a major scientific project—one that would later win the Nobel Prize for the first detection of Gravitational Waves, almost exactly 100 years after Albert Einstein predicted their existence. At the Laser Interferometer Gravitational-Wave Observatory (LIGO), we had dozens of instances of these “basic web resources” managed locally across partner universities like Caltech, MIT, and Penn State.

Every resource required a local administrator to spin up the service and manually manage local user accounts. The result? Scientists walked around with literal pocket notebooks crammed full of usernames and passwords just to access the basic tools they needed to do their jobs. When a password was forgotten, researchers often didn’t even know who to contact. Thousands of hours of highly productive scientific and IT staff time were lost chasing down support tickets.

2. Centralizing the Identity: The Single Credential Store

The first logical step out of this chaos is to centralize account directories and attributes into a single credential repository.

Over the years, various technologies have filled this space (such as NIS/NIS+), but variations of LDAP (Lightweight Directory Access Protocol) and Microsoft’s Active Directory (AD) emerged as the dominant solutions. By moving credentials into a central store and utilizing standard protocols, organizations finally achieved a foundational milestone: “one account to rule them all.” Furthermore, LDAP and AD schemas allowed centralized groups, roles, and administrative attributes to be paired directly with the identity.

3. Streamlining the Experience: Single Sign-On (SSO)

While a single credential store reduces password fatigue, it doesn’t solve workflow friction. Users still have to authenticate individually to every single service they want to access during the workday.

To solve this, Single Sign-On (SSO) was introduced. Kerberos was an early pioneer in this space, issuing a “ticket-granting ticket” (TGT) that allowed users to authenticate once and securely access multiple enterprise services for the lifetime of that ticket. While web-native extensions like SPNEGO made Kerberos usable in browsers, it was never designed with the modern web as its primary use case.

In the early-to-mid 2000s, the Security Assertion Markup Language (SAML) arrived to specifically address Web Browser SSO. SAML clearly defined three distinct roles:

  1. The Principal: Typically the end user.
  2. The Identity Provider (IdP): The organization’s central credential repository.
  3. The Service Provider (SP): The web resource or application requesting identity confirmation.

With SAML, a user authenticates to their local IdP once per session, and the IdP securely asserts their identity via XML browser redirects to any internal SP that trusts it.

4. The Scaling Trap: Bilateral vs. Multilateral Federation

Once an organization successfully wires its internal applications to a SAML IdP, a beautiful question inevitably emerges: “Wouldn’t it be nice if an astrophysicist from MIT visiting a LIGO observatory could leverage their home institution’s credentials to access resources hosted by Caltech—without submitting a support ticket or signing up for a new account?”

This is the promise of Federated Identity. Unfortunately, this is also where many enterprise, federal, and commercial organizations take a catastrophic half-step: they land in a Bilateral Federation.

The Bilateral n2n^2 Complexity Trap

In a bilateral architecture, every single relationship between an IdP and an SP requires an explicit, standalone, manual integration agreement.

[ IdP 1 ] <---> [ SP A ]
[ IdP 1 ] <---> [ SP B ]
[ IdP 2 ] <---> [ SP A ]
...and so on, scaling exponentially.

As the number of entities (nn) grows, the integration complexity scales at an unsustainable rate of O(n2)O(n^2).

  • Metadata must be manually exchanged over email or ticket queues.
  • Key Rollover becomes an absolute nightmare, often requiring synchronous “flag day” events across multiple organizations just to update an expiring certificate.
  • Every single connection becomes a snowflake of custom attribute release sets, distinct SAML NameID formats, custom assertion lifetimes, and proprietary encryption settings.

Many commercial Identity-as-a-Service (IDaaS) platforms claim to solve this pain. But the reality is that they are merely selling a sleek graphical interface to make the day-to-day manual maintenance of a bilateral federation slightly less miserable. They do not solve the underlying architectural flaw.

The Multilateral Sanctuary

In Higher Education, Research, and National Research and Education Networks (NRENs), a completely different path was forged: Multilateral Federation.

In a managed multilateral federation, an independent entity known as the Federation Operator (such as InCommon in the United States or SUNET in Sweden) is introduced. Instead of every participant exchanging metadata with everyone else, a trusted hub-and-spoke configuration fabric is established:

  1. Bilateral to the Operator: Every Identity Provider and Service Provider manages exactly one relationship—the one with the Federation Operator. Organizations submit and maintain their own entity metadata in a central repository.
  2. Aggregated and Signed Trust: The Federation Operator aggregates the metadata of all participating entities globally, cryptographically signs the combined file using an XML-DSIG (acting as a specialized Certificate Authority for SAML), and distributes this trusted aggregate root back to all participants.
  3. Instantaneous Scaling: The n2n^2 problem completely vanishes. The configuration model scales linearly as an O(n)O(n) problem. The moment an IdP or SP loads the operator’s signed metadata file, they become instantly and securely “aware” of thousands of other participants globally.
[ IdP 1 ] ---\                      /---> [ SP A ]
[ IdP 2 ] ----+--> [ Fed Operator ] +---> [ SP B ]
[ IdP 3 ] ---/                      \---> [ SP C ]

5. A Thriving Global Ecosystem

Two decades after it was first envisioned, multilateral federation is a thriving global ecosystem supporting millions of users and tens of thousands of services daily.

Through eduGAIN, national-scale federations interfederate globally. A student or researcher in the US can effortlessly log in to an Italian university’s computing resource using their hometown credentials. Similarly, eduroam leverages federated network infrastructure to allow a scholar to step off a plane in Sweden and automatically connect to secure, high-speed campus Wi-Fi using their home institution’s credentials.

Furthermore, multilateral federation introduces advanced scaling concepts that commercial tools simply cannot replicate natively:

  • Entity Categories: Standards like Research & Scholarship (R&S) allow IdP administrators to set a single, global default attribute release policy. If a Service Provider is officially vetted and categorized under R&S, the IdP securely releases a standard bundle of identity attributes automatically, stripping away per-entity configuration overhead.
  • Protocol Bridging: Projects like CILogon securely bridge SAML assertions directly into short-lived X.509 certificates, unlocking seamless federated access to high-performance compute clusters.
  • Rapid Response Capabilities: When the SARS-CoV-2 pandemic emerged, the National Institutes of Health (NIH) successfully doubled down on their federated access model to rapidly scale global scientific collaboration overnight without administrative bottlenecks.

6. Where Do We Go From Here?

Despite these undeniable architectural advantages, the commercial and federal sectors have yet to reach the same level of cooperation or velocity. It’s common to hear enterprise IT departments quip that “multilateral federation is just that complex SAML stuff Higher Ed does” or that “SAML is dead.”

This is a profound misunderstanding. Open-source identity stacks (like Shibboleth and Grouper) have natively supported these highly sophisticated multilateral use cases for years. The limitation in commercial tooling isn’t an inability to code features; it’s a fundamental flaw in their philosophical approach to identity. Commercial vendors view federation strictly through a bilateral, tenant-to-tenant lens.

To bridge this gap and bring true scaling to defense, federal, finance, and healthcare sectors, our identity communities must push forward on three fronts:

1. Demand True Commercial Support

We must actively pressure commercial IAM vendors to redesign how they conceptualize trust boundaries. The first vendor to move past basic bilateral setups and natively support multilateral frameworks will capture a massive, unserved market. A great starting point is demanding native compliance with SAML2int (the deployment profile that unifies SAML interoperability) and dynamic Entity Categories.

2. Socialize the Federation Operator Model

Moving to multilateral federation requires a cognitive leap. We must continue speaking at conferences, identity working groups, and technical exchange meetings to educate enterprise architects on the long-term cost, security, and operational benefits of standing up sector-specific Federation Operators.

3. Cross-Pollinate Communities of Interest

The Research & Education sector has spent twenty years refining governance bodies, legal trust frameworks, and highly scalable identity registries. Other high-stakes sectors—such as the Department of Defense, federal agencies, healthcare, and finance—must actively collaborate with organizations like REFEDS and GEANT to stop reinventing the wheel with fragile, custom SAML proxies and instead deploy true, mature multilateral trust fabrics.

This exploration of identity architecture is an ongoing journey. What friction points are you experiencing in your enterprise federation architectures? Let’s discuss in the comments below.

Work in progress… to be continued.

Identity & Access Management IAMSAMLFederationInCommonShibbolethEnterprise Architecture