変更要約: SC-300 第2章を新規作成（ドメイン1後半: External ID/B2B コラボレーション/External collaboration 設定/Cross-tenant access 設定/cross-tenant 同期、外部 IdP/direct federation/SAML/WS-Fed/ソーシャル IdP、ハイブリッド ID: Entra Connect Sync/Cloud Sync/PHS/PTA/シームレス SSO/Connect Health/AD FS 移行）。
2.2外部 ID プロバイダーとフェデレーション
外部 ID プロバイダー（IdP）の構成と、SAML・WS-Fed などのフェデレーションプロトコルによる認証の委譲を理解します。
外部ユーザーやパートナーが、すでに別の ID プロバイダー（IdP）を使っていることがあります。Entra は フェデレーション でその IdP に認証を委譲し、ユーザー体験を損なわずに受け入れられます。
2.2.1外部 IdP の構成
外部 ID プロバイダー を構成すると、ゲストが自分の組織/ソーシャル ID でサインインできます。エンタープライズ間では SAML または WS-Fed を話す IdP とフェデレーション（direct federation）を設定し、相手のメールドメインのユーザーをその IdP へ誘導します。これにより「相手が Entra を使っていなくても」B2B で受け入れられます。Google などのソーシャル IdP も外部 ID として追加できます。
2.2.2SAML / WS-Fed とプロトコルの選択
SAML（Security Assertion Markup Language）と WS-Fed（WS-Federation）は、企業 SSO で広く使われる XML ベースのフェデレーションプロトコルです。direct federation では相手 IdP がどちらを話すかに合わせて構成します。一方、モダンなアプリ統合や API は OpenID Connect（OIDC）/OAuth 2.0 を使います（次章のアプリ登録）。「既存の企業 IdP と SSO 連携」なら SAML/WS-Fed、「新規のモダンアプリ」なら OIDC、と使い分けます。
決め手：「相手が別の企業 IdP（メールドメイン単位）で SAML/WS-Fed を話す」＝外部 IdP との direct federation。「Google などソーシャル」＝外部 ID プロバイダー追加。「新規モダンアプリ/API の認証」＝OIDC/OAuth（外部 IdP のフェデレーションとは別レイヤ）。
混同に注意：
①外部 IdP フェデレーション（受け入れ側：ゲストの認証を相手 IdP に委譲）と、ハイブリッド ID の AD FS フェデレーション（自社オンプレ AD の認証）を取り違えない。
②SAML/WS-Fed（企業 SSO）と OIDC/OAuth（モダンアプリ）は別用途。
③direct federation はメールドメイン単位で設定する。
2.2.3この節のまとめ
- 外部 IdP との direct federation で、相手の SAML/WS-Fed IdP に認証を委譲しメールドメイン単位で受け入れる
- SAML/WS-Fed＝企業 SSO、OIDC/OAuth＝モダンアプリ。用途で使い分ける
- 外部 IdP フェデレーション(ゲスト受け入れ)と AD FS フェデレーション(自社オンプレ認証)は別物
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. パートナー企業が自社の SAML ID プロバイダーを持っており、そのドメインのゲストを相手 IdP で認証させたい。最適なのはどれですか？
Q2. 外部 IdP フェデレーション（ゲスト受け入れ）と AD FS フェデレーション（自社オンプレ認証）の違いとして正しいのはどれですか？
Q3. 新規に開発するモダンアプリの認証に最も適したプロトコルはどれですか？
Q4. direct federation の構成単位として正しいのはどれですか？
Q5. ゲストが Google アカウントでサインインできるようにしたい。最適なのはどれですか？