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?

1. Single Sign-On (SSO): Users can log in once and access resources across multiple systems.

2. No Password Fatigue: Reduces need to remember multiple credentials.

3. Improved Security: Uses token-based authentication (e.g., SAML, OAuth).

4. Delegated Authentication: Authentication is handled by a trusted Identity Provider (IdP).

5. 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

1. Go to Azure Portal.

2. 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)

1. Switch to Company B tenant.

2. Go to Azure AD > Enterprise Applications > New Application.

3. Choose “Non-gallery application”, name it CompanyA_SSO_App.

4. Go to Single sign-on > Choose SAML.

5. 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)

1. Switch to Company A tenant.

2. Go to Azure AD > App registrations > New Registration.

3. Register app with:

   • Redirect URI: https://companyb.com/app/login/callback

4. Go to Enterprise Applications > Your App > SSO > SAML.

5. Copy the Federation Metadata XML link and download the file.

Step 4: Configure Identity Provider (IdP) Info in Company B

1. Back to Company B’s app (CompanyA_SSO_App).

2. Under SAML SSO settings, upload the metadata file from Company A.

3. Save configuration.

Step 5: Test SSO

1. Create a test user in Company A tenant.

2. Assign the user to the app via Enterprise Applications > Users and Groups.

3. Now visit: https://myapps.microsoft.com and try logging in using Company A credentials.

4. 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: