Federation

Federation is a trust relationship between two different identity systems. It allows users from one organization (or domain) to access resources in another organization without creating a separate identity (username/password) in the second system.
Why Do We Use Federation?
Single Sign-On (SSO): Users can log in once and access resources across multiple systems.
No Password Fatigue: Reduces need to remember multiple credentials.
Improved Security: Uses token-based authentication (e.g., SAML, OAuth).
Delegated Authentication: Authentication is handled by a trusted Identity Provider (IdP).
Cross-organization collaboration: Seamless access between partner organizations or cloud services.
Where Is Federation Used?
Cloud services: Logging into AWS, Azure, or Salesforce using your company credentials.
Enterprise SaaS apps: Office 365, Google Workspace, Slack.
Education systems: Students use their college login to access research portals like IEEE, JSTOR.
Partner access: A vendor accesses your system using their own company credentials via federation.
Real-Life Example with a Practical Lab
🎯 Scenario:
You work at Company A, and your app is hosted in Company B’s environment. You want users from Company A to access the app in Company B without creating new accounts in Company B.
Federation Lab Using Azure AD (Free Tier) with SAML
🛠️ Goal:
Set up federation between two Azure AD tenants using SAML-based SSO.
🧰 Tools Needed:
2 Azure AD tenants (free tier is fine)
Enterprise Application setup
SAML metadata exchange
🪜 Step-by-Step Lab Instructions:
Step 1: Create 2 Tenants in Azure AD
Go to Azure Portal.
Click on your account > Switch Directory > + Create a tenant.
Tenant A (IdP):
companyA.onmicrosoft.com
Tenant B (SP):
companyB.onmicrosoft.com
Step 2: Setup Enterprise Application in Company B (SP)
Switch to Company B tenant.
Go to Azure AD > Enterprise Applications > New Application.
Choose “Non-gallery application”, name it
CompanyA_SSO_App
.Go to Single sign-on > Choose SAML.
Under Basic SAML Configuration:
Identifier (Entity ID):
https://companyb.com/app
Reply URL (Assertion Consumer Service):
https://companyb.com/app/login/callback
Step 3: Get SAML Metadata from Company A (IdP)
Switch to Company A tenant.
Go to Azure AD > App registrations > New Registration.
Register app with:
- Redirect URI:
https://companyb.com/app/login/callback
- Redirect URI:
Go to Enterprise Applications > Your App > SSO > SAML.
Copy the Federation Metadata XML link and download the file.
Step 4: Configure Identity Provider (IdP) Info in Company B
Back to Company B’s app (CompanyA_SSO_App).
Under SAML SSO settings, upload the metadata file from Company A.
Save configuration.
Step 5: Test SSO
Create a test user in Company A tenant.
Assign the user to the app via Enterprise Applications > Users and Groups.
Now visit:
https://myapps.microsoft.com
and try logging in using Company A credentials.You should be redirected to the Company B application without creating a new account.
🎥 Real-Life Analogy:
Logging into Spotify using your Google or Facebook account.
Google is your Identity Provider (IdP).
Spotify is the Service Provider (SP).
This is OAuth/OIDC federation in action.
🧠 Summary:
Topic | Description |
Federation | Trust between IdP and SP for user authentication |
Why? | SSO, security, user experience |
Where? | Cloud apps, B2B access, education, SaaS |
Protocols | SAML, OAuth, OpenID Connect |
Lab | Azure AD federation between two tenants via SAML |
Subscribe to my newsletter
Read articles from Shahrukh Ahmad directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Shahrukh Ahmad
Shahrukh Ahmad
Passionate about coding and the limitless possibilities of cloud technology. I thrive on turning ideas into scalable, efficient solutions. Let's connect and explore the exciting synergy between code and the cloud! 🤖 AI / ML🧠| 📊 - Data Science |Azure☁️AWS | Linux🐧| Windows🖥️| Python | JAVA | 🐳 Docker | Git | Gitlab | ⚓️Kubernetes | 🚀 Jenkins CI/CD | 🏗️ terraform | SQL.