Identity federation
Identity federation: trusting identities across organizational or cloud boundaries via standards like SAML and OIDC.
Federation lets one system trust identities authenticated by another, so users access many services with one identity across domains using SAML, OIDC or WS-Fed.
- Federation = trusting identities across boundaries
- Standards: SAML 2.0, OIDC, WS-Federation
- Enables SSO across organizations and clouds
- Complements governance rather than replacing it
Identity federation is a trust arrangement that lets one system accept identities that were authenticated by another, across organisational or cloud boundaries. Instead of every application maintaining its own set of credentials, a federation establishes trust between an identity provider (IdP), which authenticates users, and one or more service providers (SPs), which accept the IdP's word. It is the mechanism that makes single sign-on across dozens or hundreds of applications possible.
The problem federation solves
Without federation, each application is an island: its own usernames, its own passwords, its own login screen. Users juggle dozens of credentials, help desks drown in password resets, and deprovisioning is a nightmare because access lives in a hundred places. Federation collapses authentication to a single trusted source, so a user proves who they are once and is accepted everywhere in the trust circle.
The standards
- SAML 2.0: the long-established XML-based standard for enterprise web SSO. The IdP sends the SP a signed XML assertion vouching for the user.
- OpenID Connect (OIDC): the modern standard, built on OAuth 2.0, using JSON web tokens. It dominates newer and mobile-friendly integrations.
- WS-Federation: an older Microsoft-centric protocol still seen in legacy estates.
All three achieve the same goal, cross-domain trust, and differ mainly in token format and era.
How federation and governance divide the work
This is the key point for a SailPoint practitioner. Federation and governance are complementary, not competing:
- Federation (the IdP) handles authentication: proving identity and enforcing MFA across the trust circle.
- Governance (SailPoint) handles authorization: deciding what those federated identities are allowed to do, and keeping that access appropriate.
A federated login gets a user through the door; governance decides which rooms they may enter and continuously checks that the list is still correct. In a typical architecture, users reach both SailPoint and their applications through the same IdP, and SailPoint governs the access that federation then honours.
Federation, SSO and provisioning together
Federation is often confused with provisioning, but they are different layers. Federation lets a user log in to an app; provisioning ensures the user account and entitlements exist in that app in the first place. Many SaaS integrations pair SAML/OIDC federation for login with SCIM provisioning for account lifecycle, and SailPoint governs the provisioning side.
Common pitfalls
- Expired signing certificates silently break federation; track and rotate them ahead of expiry.
- Clock skew between IdP and SP invalidates time-bound assertions.
- Assuming federation covers deprovisioning: disabling SSO does not always remove the underlying account; pair federation with governed provisioning.
- Attribute mismatch: the identifier the IdP asserts must match what the SP and SailPoint expect, or accounts fail to correlate.