Federated Identity with Third Parties

Trust Beyond Your Own Walls

Your organization has 5,000 employees, strong MFA, and a well-managed identity store. Then you acquire a company with 2,000 employees running a completely different identity platform. A strategic partner needs access to your supply chain portal. A cloud vendor needs service account access to your analytics pipeline. Suddenly, your identity boundary extends far beyond the systems you control.

Federation is the architectural answer to a business reality: organizations do not operate in isolation, and identity management cannot stop at the network perimeter.

This module covers CISSP objective 5.3: federated identity with a third party. The exam tests whether you can evaluate federation architectures, select trust models, and govern third-party identity relationships — not configure SAML metadata files.

Federation Fundamentals

Identity federation allows users from one organization to access resources in another organization without creating separate accounts. Each organization manages its own identities; federation creates the trust bridge between them.

Key Roles

• Identity Provider (IdP) — The organization that authenticates the user and asserts their identity. The IdP owns the user’s credentials and is responsible for authentication strength. When you log into a partner’s system using your corporate credentials, your organization is the IdP.
• Service Provider (SP) — The organization that provides the resource and trusts the IdP’s assertion. The SP makes authorization decisions based on the identity information the IdP provides. The SP never sees the user’s credentials.
• Trust relationship — A pre-configured agreement between IdP and SP that defines what identity information will be shared, how it will be formatted, and how assertions will be cryptographically verified. Without this trust relationship, the SP has no reason to accept the IdP’s claims.

The fundamental trade-off in federation: the SP delegates authentication to the IdP, which improves user experience and reduces account sprawl. But the SP now depends on the IdP’s security practices. If the IdP is compromised, every SP that trusts it is exposed.

SAML Assertions

SAML is the dominant federation protocol for enterprise web SSO. A SAML assertion is an XML document that the IdP sends to the SP after authenticating the user.

A SAML assertion contains three types of statements:

• Authentication statement — Confirms that the user was authenticated, when, and how (password, MFA, certificate). The SP can use this to enforce minimum authentication strength requirements — for example, rejecting assertions that used password-only authentication.
• Attribute statement — Carries user attributes such as name, email, role, department, or group memberships. The SP uses these attributes for authorization decisions.
• Authorization decision statement — Indicates whether the user is authorized for a specific resource. Less commonly used because most SPs make their own authorization decisions based on the attributes.

SAML assertions are digitally signed by the IdP. The SP validates the signature using the IdP’s public key (exchanged during trust setup). This prevents assertion tampering and ensures the assertion genuinely came from the trusted IdP.

OAuth 2.0 Flows

While SAML handles web SSO, OAuth 2.0 handles delegated authorization — allowing applications to access resources on behalf of a user or service.

Authorization Code Flow

The most common and secure flow for web applications with a server-side backend:

1. The application redirects the user to the authorization server
2. The user authenticates and consents to the requested permissions
3. The authorization server sends an authorization code back to the application
4. The application exchanges the code for an access token through a back-channel request (server-to-server)
5. The application uses the access token to call the resource API

The authorization code flow keeps the access token out of the browser. The code itself is short-lived and useless without the application’s client secret.

Client Credentials Flow

Used for service-to-service communication where no user is involved:

1. The application presents its own credentials (client ID and secret) to the authorization server
2. The authorization server validates the credentials and issues an access token
3. The application uses the token to access the resource API

This flow is appropriate for backend services, batch processes, and API integrations where the application acts on its own behalf rather than on behalf of a user.

OpenID Connect in Federation

OpenID Connect (OIDC) layers authentication on top of OAuth 2.0. In a federation context, OIDC is increasingly replacing SAML for new implementations because it is simpler, JSON-based rather than XML, and designed for modern web and mobile applications.

• The IdP issues an ID token (a signed JWT) that contains the user’s identity claims
• The SP validates the ID token’s signature and extracts identity information
• An access token is also issued for authorizing API calls
• A UserInfo endpoint provides additional user attributes on request

For the exam: SAML and OIDC both solve the web SSO federation problem. SAML is enterprise-focused, XML-based, and mature. OIDC is developer-friendly, JSON-based, and dominant in cloud-native and mobile environments. Neither is inherently better — the choice depends on the ecosystem.

Federation Trust Models

When multiple organizations need to federate, the trust architecture determines how identities are verified across boundaries.

Cross-Certification (Peer-to-Peer)

Each organization directly trusts each other’s IdP. Organization A trusts Organization B, and B trusts A. This works for a small number of partners but scales poorly — with 10 organizations, you need 45 bilateral trust relationships.

Bridge CA / Hub-and-Spoke

A central bridge authority establishes trust with each organization. Instead of trusting each other directly, organizations trust the bridge, and the bridge vouches for participants. This scales better: 10 organizations need only 10 trust relationships (each to the bridge) instead of 45.

The Federal Bridge Certification Authority (FBCA) is a real-world example used by U.S. government agencies to enable cross-agency PKI trust.

Third-Party Trust

All parties trust an independent third-party identity provider. Cloud-based IDaaS platforms often serve this role — all organizations connect to the same identity platform, and it brokers trust between them. This model transfers significant control and risk to the third party.

Cloud Identity Federation

Cloud environments have made federation the default rather than the exception. Most organizations now federate with dozens of SaaS applications, cloud infrastructure providers, and partner ecosystems.

• Cloud-to-enterprise federation — The on-premises IdP (typically Active Directory via ADFS or Azure AD) authenticates users, and cloud SPs accept the assertion. Users access cloud applications with their corporate credentials.
• Cloud-to-cloud federation — One cloud identity provider trusts another. For example, an organization using Azure AD federates with a partner using Google Workspace.
• Multi-cloud federation — An organization using AWS, Azure, and GCP federates a single identity source across all three, so users and service accounts do not need separate credentials per provider.

Identity as a Service (IDaaS)

IDaaS platforms (Okta, Azure AD, Ping Identity) provide identity management, SSO, MFA, and federation as a cloud service. The organization offloads identity infrastructure to a specialized provider.

Benefits include faster federation setup with pre-built connectors, managed MFA, and centralized access governance. The risk is concentration — the IDaaS platform becomes the single point of trust for all connected applications. An IDaaS outage or breach affects every federated service.

Third-Party Access Governance

Federation makes access easier to provision. That same ease makes it easier to over-provision, forget about, or lose track of third-party access.

• Minimum necessary access — Federated users from partner organizations should receive only the specific permissions their role requires. Broad access grants based on the federation relationship alone violate least privilege.
• Attribute-based decisions — The SP should make authorization decisions based on attributes in the assertion (role, department, project affiliation) rather than granting blanket access to all federated users.
• Regular access reviews — Federation relationships should be reviewed periodically. Do we still need this partner to access our systems? Have their users changed roles? Has their security posture changed?
• Monitoring and logging — All federated access should be logged with the same detail as internal access. Anomalous access patterns from federated partners should trigger alerts.

Onboarding and Offboarding Federation Partners

Establishing a federation relationship should follow a structured process:

1. Due diligence — Assess the partner’s identity management practices. What authentication strength do they require? How do they manage credential lifecycle? What is their incident response process?
2. Trust agreement — Document the technical trust configuration, the data that will be shared in assertions, the minimum authentication requirements, liability, and incident notification obligations.
3. Technical implementation — Exchange metadata, configure trust parameters, test assertion flows, and validate attribute mapping.
4. Ongoing governance — Schedule periodic reviews of the relationship, access patterns, and the partner’s security posture.

Offboarding is equally structured but more urgent. When a partnership ends, the trust relationship must be terminated immediately. Any delay means the former partner’s users may still be able to authenticate to your systems through cached tokens or unrevoked trust configurations.

Pattern Recognition

Federation questions follow consistent structures:

• Trust dependency — A scenario where the SP is compromised because the IdP was compromised. The lesson: federation security is only as strong as the weakest IdP in the trust chain.
• Protocol selection — A scenario describes a use case (enterprise web SSO vs. mobile API vs. service-to-service). Match the protocol to the use case.
• Orphaned access — A former partner’s users still have access because the federation trust was never revoked. The answer involves governance: access reviews and partner offboarding procedures.
• Assertion trust — A question about how the SP knows the assertion is legitimate. The answer involves digital signatures and the pre-exchanged trust configuration.

Trap Patterns

Watch for these wrong answers:

• “Federation eliminates the need for access governance” — Federation simplifies authentication but does not replace authorization governance. The SP still must control what federated users can access.
• “The SP authenticates the user in federation” — The IdP authenticates. The SP trusts the IdP’s assertion. The SP never sees credentials.
• “Cross-certification scales well” — Cross-certification (peer-to-peer) requires bilateral trust between every pair of organizations. It scales poorly compared to bridge or hub-and-spoke models.
• “SAML and OAuth serve the same purpose” — SAML provides authentication assertions for web SSO. OAuth provides authorization tokens for resource access. They solve different problems, though OIDC bridges the gap by adding authentication to OAuth.
• “IDaaS eliminates federation risk” — IDaaS centralizes federation management but also centralizes risk. A breach of the IDaaS platform affects every connected organization and application.

Scenario Practice

Question 1

A manufacturing company has been sharing supply chain data with a key partner through a federated portal for three years. The partnership ended six months ago, but the IT team never removed the SAML trust configuration. During a routine audit, the security team discovers that three former partner employees accessed the portal last month.

What is the PRIMARY governance failure?

A. The SAML assertion signing keys were not rotated after the partnership ended
B. The partner should have disabled their employees’ accounts when the partnership ended
C. The organization had no partner offboarding procedure to revoke the federation trust when the relationship ended
D. The portal should have required re-authentication for each session

Question 2

A government agency needs to establish identity federation with 15 other agencies. Each agency operates its own PKI and identity management system. A direct cross-certification approach would require each agency to establish bilateral trust with every other agency.

What federation trust model is MOST appropriate?

A. Have each agency trust every other agency directly through cross-certification
B. Select the largest agency as the central IdP and have all others trust it
C. Implement a bridge CA that each agency trusts, enabling transitive trust across all participants
D. Migrate all agencies to a single shared identity platform

Question 3

A SaaS company receives SAML assertions from enterprise customers who use the platform. One enterprise customer reports that a former employee accessed the SaaS platform two weeks after being terminated. The IdP shows the user was deprovisioned on their termination date.

What is the MOST likely cause?

A. The SAML assertion was forged because the signing key was compromised
B. The SaaS platform cached the user’s session and did not re-validate the assertion before the session expired
C. The enterprise customer’s IdP continued sending assertions for the terminated user
D. The user created a local account on the SaaS platform that bypassed federation

Key Takeaway

Federation extends your identity boundary to organizations you do not control. Every federation relationship is a trust decision: you are accepting another organization’s assertion that a user is who they claim to be, based on authentication practices you did not design and infrastructure you cannot audit. The exam expects you to treat federation as a governance discipline. Choose trust models that scale. Validate assertion claims against your own authorization policies. Monitor federated access with the same rigor as internal access. And always have an offboarding plan — trust relationships that outlive business relationships are silent attack surfaces.