Federation
A trust relationship between multiple organizations allowing users to access resources across domains using their home identity.
What is Federation?
Identity Federation is a trust relationship established between multiple organizations to share and manage user identities across different domains and identity providers.
In a federated system:
- Home Organization: The organization where the user's identity originates (Home IdP)
- Partner Organizations: Organizations that trust the Home IdP and provide services (Partner SPs)
- Federation Standards: SAML 2.0, OpenID Connect, or WS-Federation protocols
Federation enables cross-domain SSO - a user from Organization A can access resources in Organization B without creating a new account, using their home organization credentials.
Federation is commonly used in B2B partnerships, higher education (InCommon federation), and government (FICAM).
Analogy
Think of federation like a university exchange program. Students from University A (home IdP) can attend University B (partner SP) and access their library, dorms, and classes using their University A student ID. The universities trust each other's identity systems.
Types and Use Cases
- B2B Federation: Partners use their corporate credentials to access vendor portals (Okta-Azure AD federation)
- Higher Education: Students use home university credentials to access resources at partner universities (InCommon)
- Government: Agencies share identities across federal, state, and local governments (FICAM)
- Supply Chain: Suppliers access manufacturer's systems using their own corporate IdP
How it Works
<!-- Federation Metadata Exchange (SAML) -->
<!-- Organization A (IdP) Metadata -->
<EntityDescriptor entityID="https://idp.org-a.com">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo>...</KeyInfo>
</KeyDescriptor>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://idp.org-a.com/sso"/>
</IDPSSODescriptor>
</EntityDescriptor>
<!-- Organization B (SP) Metadata -->
<EntityDescriptor entityID="https://sp.org-b.com">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="encryption">
<KeyInfo>...</KeyInfo>
</KeyDescriptor>
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sp.org-b.com/acs"/>
</SPSSODescriptor>
</EntityDescriptor>Federation vs SSO (Single Sign-On)
Federation
SSO (Single Sign-On)
Federation is cross-domain/cross-organization
SSO is typically within the same organization
Federation requires explicit trust relationships between organizations
SSO is within trusted internal systems
Federation is used for B2B, partners, education
SSO is used for internal enterprise applications
Best Practices for Federation
- Use standard protocols: Implement SAML 2.0 or OIDC for interoperability between organizations
- Secure metadata exchange: Carefully validate and securely exchange federation metadata and certificates
- Define attribute release policies: Control what user attributes are shared with partner organizations
How LoginRadius Powers Federation
LoginRadius CIAM platform provides comprehensive B2B Federation capabilities. We support federation as both Service Provider (connect to partners' Okta, Azure AD via SAML/OIDC) and Identity Provider (allow partners to use their corporate IdP). LoginRadius handles federation metadata exchange, attribute mapping between organizations, and provides detailed federation audit logs. We also support social federation (Google, Facebook, 40+ providers) and custom federation scenarios for complex B2B ecosystems.
Resources
FAQs
SSO typically refers to accessing multiple applications within the same organization (using Okta to access Salesforce, Slack, Workday). Federation refers to accessing resources across different organizations (using your company's IdP to access a vendor's portal). Federation is cross-domain; SSO is typically within-domain.
B2B Federation allows business partners to access each other's applications using their own corporate credentials. For example: (1) Vendor portal: Suppliers access manufacturer's systems using their own Okta/Azure AD, (2) Partner ecosystem: Consultants access client's systems using their consulting firm's IdP, (3) Supply chain: Logistics partners access retailer's inventory systems. B2B Federation eliminates the need to create/maintain accounts in partner systems.
LoginRadius supports B2B Federation through: (1) As SP: Connect to your partners' IdPs (Okta, Azure AD) via SAML/OIDC so they can access your portals, (2) As IdP: Allow your customers to use their corporate IdP to access your applications, (3) Social Federation: Federate with social providers (Google, Facebook) for consumer access, (4) Custom Federation: Build custom federation scenarios using our APIs. LoginRadius provides federation metadata management, attribute mapping, and detailed federation logs.