# Federated Identity and Trust Models
Federated identity is the practice of establishing verifiable trust in an identity assertion that originates from an external organization, so that a user authenticated by their own employer can access resources owned by a partner, customer, or government agency without creating a second, redundant account. The federation relationship answers a specific question: "If your identity provider says this person is who they claim to be, should we trust that assertion enough to grant access here?"
Trust in federated identity is not implicit. It is established through formal agreements, technical integrations, and cryptographic verification. When two organizations federate, they agree on a protocol (the technical handshake), an assertion format (what claims will be exchanged), and a trust anchor (how those claims will be signed and verified). Without all three components aligned, federation fails, either technically or, more dangerously, silently.
The practical value of federation is significant. A defense contractor with 800 employees working on a government project should not need 800 separate .gov accounts managed by a federal IT team. The contractor's identity provider, already enforcing MFA and device compliance, vouches for each employee. The government agency's systems verify that voucher cryptographically and grant scoped access. Nobody manages a second set of credentials. Offboarding is automatic: when the contractor's HR system deactivates the employee, the federation assertion stops being issued, and access evaporates.
Federation operates through three primary protocols, each reflecting a different era and ecosystem of identity management.
SAML 2.0 (Security Assertion Markup Language) is the dominant enterprise federation standard, ratified in 2005 and still the backbone of most corporate SSO deployments. SAML uses XML-formatted assertions signed with X.509 certificates. The flow involves three parties: the user (principal), the Identity Provider (IdP, who knows the user), and the Service Provider (SP, who controls the resource). When a user attempts to access the SP, they are redirected to the IdP. The IdP authenticates the user (password, MFA, whatever the IdP policy requires) and returns a signed XML assertion to the SP. The SP validates the signature against the IdP's public certificate and extracts the user's attributes (name, email, role, group memberships). The assertion has a short validity window (typically 5 minutes) and cannot be reused, limiting replay attack exposure. SAML is verbose, XML-heavy, and painful to debug, but it is deeply embedded in enterprise software. Salesforce, ServiceNow, Workday, AWS, and virtually every major enterprise SaaS platform support SAML 2.0.
OpenID Connect (OIDC) is the modern federation protocol, built on top of OAuth 2.0 and using JSON Web Tokens (JWTs) instead of XML. OIDC separates the authorization question (OAuth 2.0: "may this application act on the user's behalf?") from the identity question ("who is this user?"). The identity token (ID token) is a signed JWT containing claims about the authenticated user. OIDC is the protocol behind consumer SSO ("Sign in with Google," "Sign in with Microsoft") and is increasingly preferred for enterprise federation as well. It is simpler to implement, easier to parse, and better suited to modern API-first architectures. Azure AD B2B, Google Cloud Identity Federation, and most modern identity platforms default to OIDC for new integrations.
WS-Federation is an older Microsoft protocol closely tied to Active Directory Federation Services (ADFS). It handles similar use cases to SAML but using WS-Trust and WS-Security XML standards from the early 2000s. WS-Federation is still found in organizations that built their federation infrastructure around ADFS before SAML 2.0 was fully mature. New deployments rarely choose WS-Federation; it persists through inertia in legacy Microsoft environments.
Trust Models determine how many organizations need to maintain explicit bilateral agreements.
In a hub-and-spoke model, a central identity broker sits at the hub. All organizations connect their IdPs to the hub, and the hub maintains trust relationships on behalf of all participants. When Organization A's user needs to access Organization B's resources, the hub mediates: it trusts A's IdP, it trusts B's SP, and the federation flows through the hub. The hub model scales well because adding a new participant requires one new connection to the hub, not n-1 new connections to every other participant. Government federation networks like the Federal PKI and Login.gov use hub architectures for this reason.
In a mesh model, every organization maintains direct trust relationships with every other organization. At two or three participants, mesh is manageable. At ten or twenty, it becomes operationally unsustainable: 20 organizations require up to 190 bilateral trust agreements. Mesh federation is rare outside tightly controlled partnerships.
Federation brokers sit between pure hub and pure mesh. A broker is an intermediary, not an authoritative IdP, that translates between different identity protocols and maintains trust on behalf of its members. Commercial brokers (Ping Federate, Okta Identity Engine, Azure AD External Identities) allow organizations to outsource the complexity of cross-organizational federation.
The practical driver for federation is the unsustainable cost of account sprawl. When organizations manage external access through local accounts (creating contractor accounts in their own Active Directory, for example), they inherit a persistent governance burden. Every external account must be created, managed, and, critically, deprovisioned when the relationship ends. Deprovisioning is where local account management fails most catastrophically. A contractor finishes an engagement. Their contract expires. But the IT ticket to disable the account never gets filed, or gets filed and sits in the queue for three months. The account persists, often with credentials that were shared with the contractor's team and never rotated.
Federation eliminates this failure mode structurally. The external organization's IdP is the authoritative source for whether that identity is active. When the contractor's HR system deactivates the employee, the IdP stops issuing assertions for that user. The next access attempt fails, automatically, without any IT action required on the resource side.
Government federation addresses a different scale of the same problem. The U.S. federal government operates hundreds of agencies, each with populations of employees, contractors, grantees, and the general public who need access to digital services. Login.gov implements NIST 800-63 Identity Assurance Level 2 (IAL2), providing a single proofed identity that works across participating agencies. A veteran who has proofed their identity with the VA does not need to reprove it with the SSA. The federation layer carries the assurance.
The cryptographic foundation of federation is the assertion signature. In SAML, the IdP signs assertions with its private key. The SP trusts assertions signed by that key because it has the IdP's public certificate registered in its configuration. An assertion with a valid signature from a trusted IdP is accepted. An assertion with an invalid signature, or signed by an unknown key, is rejected. This makes the IdP's signing key the single most critical secret in the federation relationship.
JWTs in OIDC work similarly. The ID token is signed using RS256 (RSA + SHA-256) or ES256 (ECDSA + SHA-256). The IdP publishes its JSON Web Key Set (JWKS) at a well-known endpoint, and relying parties fetch the public keys to validate tokens. JWKS rotation (periodically replacing signing keys) is a security best practice that many implementations neglect.
Conditional access policies extend federation security beyond the basic assertion validation. Rather than accepting any valid assertion from a federated IdP at face value, conditional access evaluates additional signals: Is the device managed or compliant? Is the request originating from a known location? Has the user's risk score changed since the last authentication? If any condition is not met, access is denied or step-up authentication is required, even if the federated assertion is technically valid.
Cross-tenant access restrictions in platforms like Azure AD allow fine-grained control over which external tenants can federate inbound, which internal users can federate outbound, and what MFA and compliance claims must be present in inbound assertions. These settings are the operational implementation of a formal federation agreement.
Attribute mapping is a common point of failure in federation deployments. The IdP sends attributes (email, department, group membership) in formats and field names that may not match what the SP expects. A mismatch in attribute names ("email" vs "mail" vs "upn") can result in a technically successful federation handshake that fails to grant the correct roles. Thorough attribute mapping documentation is not optional; it is foundational to any federation integration.
CDA's IAT domain, governed by the Zero Possession Architecture (ZPA) methodology, treats federation as a trust boundary that must be actively verified, never passively assumed. The ZPA principle "Trust nothing. Possess nothing. Verify everything." applies with heightened urgency at federation boundaries, because the thing being trusted is not a credential the local system can directly control. It is an assertion from an external system, over which the relying party has limited visibility.
The SolarWinds attack illustrated the catastrophic failure mode of implicit federation trust. Attackers who compromised SolarWinds' build environment were able to forge SAML tokens, because they gained access to the ADFS signing certificate. Those forged tokens passed all technical validation checks: they were signed by the right key, they contained plausible attributes, and they fell within valid assertion time windows. The compromise was invisible to automated controls because federation validation does not evaluate whether the assertion was legitimately issued; it only checks whether the signature is valid.
CDA's operational position: federation trust is a privilege, not a default. Every federated relationship requires documented business justification, scoped attribute claims (send only what the SP needs, nothing more), assertion validity windows of five minutes or less, and monitoring for assertion anomalies (volumes, timing, attribute patterns) that deviate from baseline. Cross-tenant access restrictions should be configured to allowlist specific external tenants rather than permitting open federation. The signing keys of federated IdPs should be treated as third-party supply chain risk: their rotation, storage, and compromise notification procedures are part of vendor due diligence.
When a federated organization's IdP is compromised, every relying party that trusts that IdP is compromised by extension. This is the cascading risk that ZPA addresses: verification must occur at every boundary, not just at initial establishment of the federation relationship.