What's changed: Created SC-300 Chapter 2 (Domain 1 second-half: External ID/B2B collaboration/External collaboration settings/Cross-tenant access settings/cross-tenant sync; external IdP/direct federation/SAML/WS-Fed/social IdP; hybrid identity: Entra Connect Sync/Cloud Sync/PHS/PTA/seamless SSO/Connect Health/AD FS migration).
2.2External identity providers and federation
Understand configuring external identity providers (IdPs) and delegating authentication via federation protocols such as SAML and WS-Fed.
External users or partners may already use another identity provider (IdP). Entra can federate to delegate authentication to that IdP, accepting them without harming the user experience.
2.2.1Configuring external IdPs
Configuring an external identity provider lets guests sign in with their own organizational/social identity. Between enterprises, set up federation (direct federation) with an IdP that speaks SAML or WS-Fed, routing users of that email domain to the IdP. This accepts B2B partners "even if they do not use Entra." Social IdPs like Google can also be added as external identities.
2.2.2SAML / WS-Fed and protocol choice
SAML (Security Assertion Markup Language) and WS-Fed (WS-Federation) are XML-based federation protocols widely used for enterprise SSO. For direct federation, configure to match whichever the partner IdP speaks. Modern app integration and APIs use OpenID Connect (OIDC)/OAuth 2.0 (next chapter’s app registration). Choose SAML/WS-Fed for "SSO with an existing enterprise IdP" and OIDC for "new modern apps."
Cues: "the partner uses another enterprise IdP (by email domain) speaking SAML/WS-Fed" = direct federation with the external IdP. "Google etc. social" = add an external identity provider. "auth for new modern apps/APIs" = OIDC/OAuth (a different layer from external-IdP federation).
Watch the mix-ups: (1) Distinguish external-IdP federation (accepting side: delegate guest auth to their IdP) from hybrid-identity AD FS federation (your own on-prem AD auth). (2) SAML/WS-Fed (enterprise SSO) vs OIDC/OAuth (modern apps) serve different purposes. (3) Direct federation is configured per email domain.
2.2.3Section summary
- Direct federation with an external IdP delegates auth to their SAML/WS-Fed IdP, accepting per email domain
- SAML/WS-Fed = enterprise SSO; OIDC/OAuth = modern apps—choose by purpose
- External-IdP federation (accepting guests) and AD FS federation (your on-prem auth) are different
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. A partner company has its own SAML identity provider, and you want guests of that domain to authenticate with the partner IdP. Which is best?
Q2. Which correctly distinguishes external-IdP federation (accepting guests) from AD FS federation (your on-prem auth)?
Q3. Which protocol best fits authentication for a newly developed modern app?
Q4. What is the correct unit for configuring direct federation?
Q5. You want guests to sign in with a Google account. Which is best?