External Identity Providers (SAML and WS-Fed)

External Identity Providers (SAML and WS-Fed) – SC-300 Exam Guide

Why External Identity Providers (SAML and WS-Fed) Matter

In today's enterprise landscape, organizations frequently need to collaborate with partners, customers, and other external entities. Rather than forcing every user to create a new set of credentials in your Azure AD (now Microsoft Entra ID) tenant, you can establish trust with their existing identity provider (IdP). This is where federation with external identity providers using SAML (Security Assertion Markup Language) and WS-Fed (WS-Federation) becomes critical.

Federated authentication allows seamless single sign-on (SSO) experiences, reduces password fatigue, improves security posture, and simplifies identity lifecycle management across organizational boundaries. For the SC-300 exam, understanding how to configure and manage these federation relationships is essential.

What Are External Identity Providers (SAML and WS-Fed)?

External identity providers are third-party identity systems that your Azure AD tenant trusts to authenticate users. When you configure federation with an external IdP, you are telling Azure AD: "When a user from this domain tries to sign in, redirect them to their own identity provider for authentication, and trust the security token that comes back."

SAML 2.0 – Security Assertion Markup Language 2.0 is an open standard for exchanging authentication and authorization data between an identity provider and a service provider. It uses XML-based assertions to convey identity information. SAML is widely adopted across enterprise applications and identity platforms.

WS-Federation (WS-Fed) – WS-Federation is a protocol developed by Microsoft and others as part of the WS-* family of web service specifications. It is commonly used with Active Directory Federation Services (AD FS) and other Microsoft-centric identity solutions. Like SAML, it enables federated SSO by exchanging security tokens.

Key Differences Between SAML and WS-Fed:
- Both support browser-based SSO and use XML-based tokens
- WS-Fed is more commonly associated with Microsoft ecosystems (e.g., AD FS)
- SAML 2.0 is more widely adopted across non-Microsoft platforms
- In Azure AD B2B collaboration, both can be used as federation protocols for external identity providers
- When both are configured for the same domain, WS-Fed takes precedence in some scenarios

How External Identity Provider Federation Works

Here is the step-by-step flow of how federation with an external SAML/WS-Fed identity provider works in Azure AD:

1. Configuration Phase:
- An administrator configures a new external identity provider in the Azure AD tenant (Microsoft Entra External Identities)
- The administrator specifies the federation protocol (SAML 2.0 or WS-Fed)
- Key metadata is exchanged: the external IdP's passive authentication endpoint URL, the entity ID (issuer), and the signing certificate
- The domain(s) associated with the external IdP are specified

2. User Invitation and Redemption:
- A guest user with an email domain matching the configured federation domain is invited to the tenant
- When the guest user redeems their invitation, Azure AD detects that their email domain is associated with a federated external IdP
- Azure AD redirects the user to their external IdP for authentication

3. Authentication Flow:
- The user authenticates at their home IdP (the external SAML or WS-Fed provider)
- The external IdP issues a security token (SAML assertion or WS-Fed token) containing claims about the user
- The token is posted back to Azure AD
- Azure AD validates the token (checks signature, issuer, expiration, etc.)
- Azure AD issues its own token and grants the user access to the requested resource

4. Ongoing Access:
- On subsequent sign-ins, the same federation flow occurs automatically, providing a seamless SSO experience
- The user never needs to create or manage credentials in your Azure AD tenant

How to Configure External Identity Providers in Azure AD

Prerequisites:
- You need Global Administrator or External Identity Provider Administrator role
- The external IdP must support SAML 2.0 or WS-Fed protocol
- You must have the external IdP's metadata (passive endpoint URL, issuer URI, signing certificate)
- The domain must not already be verified in any Azure AD tenant (important restriction!)

Configuration Steps (Azure Portal):
1. Navigate to Microsoft Entra ID → External Identities → All identity providers
2. Click + New SAML/WS-Fed IdP
3. Select the protocol: SAML or WS-Fed
4. Enter the domain name of the external organization (e.g., contoso.com)
5. Enter the metadata URL or manually input:
  - Passive authentication endpoint URL
  - Entity ID / Issuer
  - Signing certificate (in .cer or .pem format)
6. Click Save

Important Configuration Considerations:
- The federated domain must not be a verified domain in Azure AD. If contoso.com is already verified in any Azure AD tenant, you cannot set up SAML/WS-Fed federation for that domain. This is a critical exam point!
- SAML/WS-Fed federation is specifically for B2B guest user scenarios
- If a domain has both SAML/WS-Fed federation and email one-time passcode enabled, SAML/WS-Fed federation takes priority
- The external IdP must support SP-initiated (service provider-initiated) authentication flows

Federation Redemption Order (Priority)

When a guest user redeems an invitation, Azure AD follows a specific order to determine which identity provider to use. Understanding this priority order is critical for the SC-300 exam:

1. Azure AD federation (if the user's domain is a verified Azure AD tenant)
2. SAML/WS-Fed identity provider federation (if configured for the domain)
3. Google federation (if configured and the user has a Gmail account)
4. Microsoft Account (MSA) (if the user has an existing Microsoft account)
5. Email one-time passcode (OTP) (if enabled)
6. Self-service sign-up (if enabled via user flows)

Limitations and Constraints

- SAML/WS-Fed federation does not work for domains that are DNS-verified in any Azure AD tenant
- The protocol requires email-based authentication; the NameID or email claim in the SAML assertion must match the user's email address
- SAML/WS-Fed federation applies only to guest users (B2B), not to internal members
- You cannot configure both SAML and WS-Fed for the same domain
- Multi-factor authentication (MFA) policies at the resource tenant still apply; the external IdP's MFA is not automatically trusted unless cross-tenant access settings are configured to trust the inbound MFA claims
- Maximum number of SAML/WS-Fed federated domains may be subject to service limits

Cross-Tenant Access Settings and MFA Trust

A related but distinct concept is cross-tenant access settings, which allow you to configure whether to trust MFA, compliant device claims, and hybrid Azure AD joined device claims from external Azure AD organizations. For SAML/WS-Fed IdPs specifically:
- The MFA trust settings in cross-tenant access apply primarily to Azure AD-to-Azure AD federation
- For SAML/WS-Fed external IdPs, MFA enforcement typically occurs at the resource tenant level via Conditional Access policies

Common Use Cases

- Partner organizations using AD FS: A partner company uses on-premises AD FS. You configure WS-Fed federation so their users can access your resources using their existing AD FS credentials.
- Organizations using non-Microsoft IdPs: A partner uses Okta, Ping Identity, or another SAML 2.0-compliant IdP. You configure SAML federation so their users authenticate against their own IdP.
- Acquisitions and mergers: During a transition period, you federate with the acquired company's existing IdP before migrating users.

Troubleshooting Common Issues

- Token validation failures: Check that the signing certificate is correct and not expired
- Redirect loops: Ensure the passive endpoint URL is correct and supports SP-initiated flows
- Claim mismatch: The email claim in the SAML assertion must match the invited user's email address
- Domain already verified: If you get an error during configuration, the domain may already be verified in an Azure AD tenant
- Federation not being used: Check the redemption priority order; Azure AD federation takes precedence over SAML/WS-Fed federation

---

Exam Tips: Answering Questions on External Identity Providers (SAML and WS-Fed)

1. Know the Redemption Priority Order: This is one of the most commonly tested concepts. Remember that Azure AD federation (verified tenant) always takes priority over SAML/WS-Fed federation. If a question describes a scenario where a partner has an Azure AD tenant with a verified domain AND you've configured SAML/WS-Fed for the same domain, Azure AD federation wins.

2. Remember the Domain Restriction: You cannot configure SAML/WS-Fed federation for a domain that is DNS-verified in any Azure AD tenant. This is a frequently tested constraint. If a question asks why SAML/WS-Fed federation setup fails, this is often the answer.

3. B2B Only: SAML/WS-Fed federation is exclusively for B2B (guest user) scenarios. If a question asks about configuring federation for internal users or B2C scenarios, SAML/WS-Fed IdP federation in External Identities is not the right answer.

4. Differentiate from Direct Federation vs. Other Federation Types: In older exam materials, SAML/WS-Fed IdP federation was called "direct federation." Know that these terms refer to the same feature. Also, do not confuse this with Azure AD B2C custom identity providers or enterprise application SSO configurations.

5. Required Metadata: Know the three key pieces of metadata needed: passive authentication endpoint URL, entity ID (issuer), and signing certificate. Questions may test whether you know which information must be exchanged.

6. Role Requirements: Configuration requires Global Administrator or External Identity Provider Administrator role. If a question mentions a user with a lesser role who cannot configure federation, the role assignment is likely the issue.

7. Protocol Selection Scenarios: If a question mentions AD FS, the answer likely involves WS-Fed. If it mentions a third-party IdP like Okta, Shibboleth, or Ping Identity, the answer likely involves SAML 2.0. However, remember that AD FS also supports SAML 2.0.

8. MFA Considerations: Remember that configuring SAML/WS-Fed federation does not automatically trust MFA performed at the external IdP. The resource tenant's Conditional Access policies still apply. If a question asks how to ensure MFA is enforced for federated guest users, Conditional Access at the resource tenant is the answer.

9. Watch for Distractor Answers: Common distractors include:
- Configuring an enterprise application for SSO (this is for your own users accessing SaaS apps, not for B2B federation)
- Setting up Azure AD B2C custom policies (this is for customer-facing scenarios, not B2B)
- Using Microsoft Account federation (this is a separate, automatic mechanism)
- Configuring Google federation (this only works for Gmail/Google Workspace accounts)

10. Scenario-Based Approach: When you encounter a scenario question, follow this mental checklist:
  a. Is this a B2B (guest user) scenario? → If yes, SAML/WS-Fed federation could apply
  b. Is the partner's domain verified in Azure AD? → If yes, Azure AD federation will be used instead
  c. What IdP does the partner use? → This determines SAML vs. WS-Fed
  d. What role does the administrator have? → Must be Global Admin or External Identity Provider Admin
  e. Are there MFA requirements? → Configure Conditional Access at the resource tenant

11. Remember Key Terminology:
- Service Provider (SP) = Your Azure AD tenant (the one requesting authentication)
- Identity Provider (IdP) = The external partner's authentication system
- Assertion = The security token containing user claims (SAML terminology)
- Passive endpoint = The URL where browser-based authentication requests are sent
- Entity ID / Issuer = The unique identifier for the IdP

12. Practice with Process of Elimination: In multiple-choice questions, eliminate answers that involve B2C configurations, enterprise app SSO configurations, or features that require the domain to be verified (which contradicts SAML/WS-Fed federation requirements). The correct answer for enabling seamless guest user authentication with a partner's non-Azure AD identity system is almost always SAML/WS-Fed IdP federation under External Identities.