Azure Active Directory B2C を使用して SAML ID プロバイダーオプションを構成する

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。詳細については、FAQ を参照してください。

Azure Active Directory B2C (Azure AD B2C) では、SAML 2.0 ID プロバイダーとのフェデレーションがサポートされています。この記事では、セキュリティアサーションを解析する方法と、SAML ID プロバイダーでのサインインを有効にするときに使用できる構成オプションについて説明します。

開始する前にこのページの上部にある ポリシーの種類 セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザーフローを使用する、または完全に構成可能なカスタムポリシーを使用する) があります。この記事で必要な手順は、方法ごとに異なります。

この機能は、カスタムポリシーでのみ使用できます。セットアップ手順については、前のセレクターで [カスタムポリシー] を選択します。

クレームマッピング

OutputClaims 要素には、SAML ID プロバイダーによって返される要求の一覧が含まれています。ポリシーで定義されている要求の名前を、ID プロバイダーで定義されている名前にマップする必要があります。 ID プロバイダーでクレーム (アサーション) の一覧を確認します。 ID プロバイダーから返される SAML 応答の内容を確認することもできます。詳細については、「 SAML メッセージのデバッグ」を参照してください。要求を追加するには、最初に要求を定義してから、出力要求コレクションに要求を追加します。

DefaultValue属性を設定している限り、ID プロバイダーから返されない要求を含めることもできます。既定値は、コンテキスト要求を使用して静的または動的にすることができます。

出力要求要素には、次の属性が含まれています。

ClaimTypeReferenceId は、要求の種類への参照です。
PartnerClaimType は、SAML アサーションが表示されるプロパティの名前です。
DefaultValue は定義済みの既定値です。要求が空の場合は、既定値が使用されます。相関 ID やユーザー IP アドレスなどのコンテキスト値を持つ要求リゾルバーを使用することもできます。

サブジェクト名

サブジェクトの SAML アサーション NameId を正規化された要求として読み取るために、要求 PartnerClaimType を SPNameQualifier 属性の値に設定します。 SPNameQualifier属性が提示されない場合は、PartnerClaimType を NameQualifier属性の値に設定します。

SAML アサーション:

<saml:Subject>
  <saml:NameID SPNameQualifier="http://your-idp.com/unique-identifier" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">david@contoso.com</saml:NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="_cd37c3f2-6875-4308-a9db-ce2cf187f4d1" NotOnOrAfter="2020-02-15T16:23:23.137Z" Recipient="https://<your-tenant>.b2clogin.com/<your-tenant>.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" />
    </SubjectConfirmation>
  </saml:SubjectConfirmation>
</saml:Subject>

出力要求：

<OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="http://your-idp.com/unique-identifier" />

SPNameQualifier属性とNameQualifier属性の両方が SAML アサーションに提示されない場合は、クレーム PartnerClaimType をassertionSubjectNameに設定します。 NameId がアサーション XML の最初の値であることを確認します。複数のアサーションを定義すると、Azure AD B2C は最後のアサーションからサブジェクト値を選択します。

SAML プロトコルバインドを構成する

SAML 要求は、ID プロバイダーのメタデータ SingleSignOnService 要素で指定されているように ID プロバイダーに送信されます。 ID プロバイダーの承認要求のほとんどは、HTTP GET 要求の URL クエリ文字列に直接送信されます (メッセージは比較的短いため)。両方の SAML 要求のバインドを構成する方法については、ID プロバイダーのドキュメントを参照してください。

次の XML は、2 つのバインドを持つ Microsoft Entra メタデータシングルサインオンサービスの例です。 HTTP-Redirectは、SAML ID プロバイダーのメタデータに最初に表示されるため、HTTP-POSTよりも優先されます。

<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
  <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2"/>
</IDPSSODescriptor>

アサーションコンシューマーサービス

アサーションコンシューマーサービス (または ACS) は、ID プロバイダーの SAML 応答が Azure AD B2C によって送受信される場所です。 SAML 応答は、HTTP POST バインディングを介して Azure AD B2C に送信されます。 ACS の場所は、信頼できる当事者の基本ポリシーを指します。たとえば、依存するポリシーが B2C_1A_signup_signin である場合、ACS は B2C_1A_TrustFrameworkBase などの B2C_1A_signup_signin の基本ポリシーとなります。

次の XML は、Azure AD B2C ポリシーメタデータアサーションコンシューマーサービス要素の例です。

<SPSSODescriptor AuthnRequestsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-tenant.b2clogin.com/your-tenant/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" index="0" isDefault="true"/>
</SPSSODescriptor>

SAML 要求署名を構成する

Azure AD B2C は 、SamlMessageSigning 暗号化キーを使用して、すべての送信認証要求に署名します。 SAML 要求署名を無効にするには、 WantsSignedRequests を falseに設定します。メタデータが false に設定されている場合、 SigAlg パラメーターと Signature パラメーター (クエリ文字列または post パラメーター) は要求から省略されます。

このメタデータは、ID プロバイダーと共有される Azure AD B2C 技術プロファイルのメタデータに含まれる AuthnRequestsSigned 属性も制御します。技術プロファイルメタデータの WantsSignedRequests の値が false に設定されていて、ID プロバイダーメタデータ WantAuthnRequestsSigned が false に設定されているか、指定されていない場合、Azure AD B2C は要求に署名しません。

次の例では、SAML 要求から署名を削除します。

<Metadata>
  ...
  <Item Key="WantsSignedRequests">false</Item>
</Metadata>

署名アルゴリズム

Azure AD B2C では、 Sha1 を使用して SAML 要求に署名します。 XmlSignatureAlgorithm メタデータを使用して、使用するアルゴリズムを構成します。使用できる値は、 Sha256、 Sha384、 Sha512、または Sha1 (既定値) です。このメタデータは、SAML 要求の SigAlg パラメーター (クエリ文字列または post パラメーター) の値を制御します。両方の側で同じ値の署名アルゴリズムを構成するようにします。証明書でサポートされているアルゴリズムのみを使用してください。

キー情報を含める

ID プロバイダーが Azure AD B2C バインディングが HTTP-POST に設定されていることを示す場合、Azure AD B2C は SAML 要求の本文に署名とアルゴリズムを含めます。バインドが HTTP-POST に設定されている場合は、証明書の公開キーを含むように Microsoft Entra ID を構成することもできます。 IncludeKeyInfo メタデータを true または false に設定します。次の例では、Microsoft Entra ID には証明書の公開キーは含まれません。

<Metadata>
  ...
  <Item Key="IncludeKeyInfo">false</Item>
</Metadata>

SAML 要求名 ID を構成する

SAML 承認要求 <NameID> 要素は、SAML 名識別子の形式を示します。このセクションでは、既定の構成と、名前 ID 要素をカスタマイズする方法について説明します。

優先ユーザー名

サインインプロセス中に、リライイングパーティーアプリケーションが特定のユーザーを対象とすることがあります。 Azure AD B2C では、優先ユーザー名を SAML ID プロバイダーに送信できます。 InputClaims 要素は、SAML 承認要求のサブジェクト内で NameId を送信するために使用されます。

承認要求にサブジェクト名 ID を含めるには、<InputClaims>の直後に次の<CryptographicKeys>要素を追加します。 PartnerClaimType をsubjectに設定する必要があります。

<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" />
</InputClaims>

この例では、Azure AD B2C は、SAML 承認要求のサブジェクト内で NameId を使用して signInName 要求の値を送信します。

<samlp:AuthnRequest ... >
  ...
  <saml:Subject>
    <saml:NameID>sam@contoso.com</saml:NameID>
  </saml:Subject>
</samlp:AuthnRequest>

などの{OIDC:LoginHint}を使用して、要求値を設定できます。

<Metadata>
  ...
  <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
</Metadata>
  ...
<InputClaims>
  <InputClaim ClaimTypeReferenceId="signInName" PartnerClaimType="subject" DefaultValue="{OIDC:LoginHint}" AlwaysUseDefaultValue="true" />
</InputClaims>

名前 ID ポリシーの形式

既定では、SAML 承認要求によって urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified ポリシーが指定されます。この名前 ID は、要求されたサブジェクトの ID プロバイダーでサポートされている任意の種類の識別子を使用できることを示します。

この動作を変更するには、サポートされている名前 ID ポリシーに関するガイダンスについては、ID プロバイダーのドキュメントを参照してください。次に、対応するポリシー形式で NameIdPolicyFormat メタデータを追加します。例えば次が挙げられます。

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
</Metadata>

次の SAML 承認要求には、名前 ID ポリシーが含まれています。

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</samlp:AuthnRequest>

新しいアカウントの作成を許可する

名前 ID ポリシー形式を指定する場合は、AllowCreate のプロパティを指定して、サインインフロー中に ID プロバイダーが新しいアカウントを作成できるかどうかを示すこともできます。ガイダンスについては、ID プロバイダーのドキュメントを参照してください。

Azure AD B2C では、既定で AllowCreate プロパティが省略されています。この動作は、 NameIdPolicyAllowCreate メタデータを使用して変更できます。このメタデータの値は、 true または falseです。

次の例では、AllowCreateNameIDPolicyプロパティを true に設定する方法を示します。

<Metadata>
  ...
  <Item Key="NameIdPolicyFormat">urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</Item>
  <Item Key="NameIdPolicyAllowCreate">true</Item>
</Metadata>

次の例は、承認要求の NameIDPolicy 要素の AllowCreate を使用した承認要求を示しています。

<samlp:AuthnRequest ... >
  ...
  <samlp:NameIDPolicy 
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" 
      AllowCreate="true" />
</samlp:AuthnRequest>

認証を強制する

SAML 認証要求で ForceAuthN プロパティを渡すことで、外部 SAML IDP に認証のプロンプトを表示させることができます。 ID プロバイダーもこのプロパティをサポートする必要があります。

ForceAuthN プロパティは、ブール値trueまたはfalse値です。既定では、Azure AD B2C は ForceAuthN 値を falseに設定します。その後、セッションがリセットされた場合 (OIDC の prompt=login を使用するなど)、 ForceAuthN 値は true に設定されます。 ForceAuthNメタデータを true に設定すると、外部 IDP に対するすべての要求の値が強制的に適用されます。

次の例は、ForceAuthNに設定されたtrue プロパティを示しています。

<Metadata>
  ...
  <Item Key="ForceAuthN">true</Item>
  ...
</Metadata>

次の例は、承認要求の ForceAuthN プロパティを示しています。

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ForceAuthN="true">
  ...
</samlp:AuthnRequest>

プロバイダー名

必要に応じて、SAML 承認要求に ProviderName 属性を含めることができます。外部 SAML IDP に対するすべての要求のプロバイダー名を含むように、 ProviderName メタデータを設定します。次の例は、ProviderNameに設定されたContoso app プロパティを示しています。

<Metadata>
  ...
  <Item Key="ProviderName">Contoso app</Item>
  ...
</Metadata>

次の例は、承認要求の ProviderName プロパティを示しています。

<samlp:AuthnRequest AssertionConsumerServiceURL="https://..."  ...
                    ProviderName="Contoso app">
  ...
</samlp:AuthnRequest>

認証コンテキストクラス参照を含める

SAML 承認要求には、承認要求のコンテキストを指定する AuthnContext 要素が含まれている場合があります。この要素には、ユーザーに提示する認証メカニズムを SAML ID プロバイダーに指示する認証コンテキストクラス参照を含めることができます。

認証コンテキストクラス参照を構成するには、 IncludeAuthnContextClassReferences メタデータを 追加します。値に、認証コンテキストクラスを識別する 1 つ以上の URI 参照を指定します。複数の URI をコンマ区切りリストとして指定します。サポートされている AuthnContextClassRef URI のガイダンスについては、ID プロバイダーのドキュメントを参照してください。

次の例では、ユーザーはユーザー名とパスワードの両方でサインインし、保護されたセッション (SSL/TLS) 経由でユーザー名とパスワードでサインインできます。

<Metadata>
  ...
  <Item Key="IncludeAuthnContextClassReferences">urn:oasis:names:tc:SAML:2.0:ac:classes:Password,urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</Item>
</Metadata>

次の SAML 承認要求には、認証コンテキストクラス参照が含まれています。

<samlp:AuthnRequest ... >
  ...
  <samlp:RequestedAuthnContext>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

承認要求にカスタムデータを含める

必要に応じて、Azure AD B2C と ID プロバイダーの両方で同意されたプロトコルメッセージ拡張要素を含めることができます。拡張機能は XML 形式で表示されます。拡張要素を含めるには、CDATA 要素 <![CDATA[Your Custom XML]]>内に XML データを追加します。 ID プロバイダーのドキュメントを調べて、拡張機能要素がサポートされているかどうかを確認します。

拡張機能データの使用例を次に示します。

<Metadata>
  ...
  <Item Key="AuthenticationRequestExtensions"><![CDATA[
            <ext:MyCustom xmlns:ext="urn:ext:custom">
              <ext:AssuranceLevel>1</ext:AssuranceLevel>
              <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
            </ext:MyCustom>]]></Item>
</Metadata>

注

SAML 仕様では、拡張データは名前空間で修飾された XML (サンプルに示されている 'urn:ext:custom' など) である必要があり、SAML 固有の名前空間にすることはできません。

SAML プロトコルメッセージ拡張機能では、SAML 応答は次の例のようになります。

<samlp:AuthnRequest ... >
  ...
  <samlp:Extensions>
    <ext:MyCustom xmlns:ext="urn:ext:custom">
      <ext:AssuranceLevel>1</ext:AssuranceLevel>
      <ext:AssuranceDescription>Identity verified to level 1.</ext:AssuranceDescription>
    </ext:MyCustom>
  </samlp:Extensions>
</samlp:AuthnRequest>

署名された SAML 応答を要求する

Azure AD B2C では、すべての受信アサーションは署名済みである必要があります。この要件を削除するには、 WantsSignedAssertions を falseに設定します。この場合、ID プロバイダーはアサーションに署名してはなりませんが、したとしても、Azure AD B2C では署名は検証されません。

WantsSignedAssertions メタデータは、ID プロバイダーと共有される Azure AD B2C 技術プロファイルのメタデータに含まれる SAML メタデータフラグ WantAssertionsSigned を制御します。

<SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

アサーション検証を無効にした場合は、応答メッセージ署名の検証を無効にすることもできます。 ResponsesSigned メタデータをfalseに設定します。この場合、ID プロバイダーは SAML 応答メッセージに署名しないでくださいが、署名が行われても、Azure AD B2C は署名を検証しません。

次の例では、メッセージとアサーション署名の両方を削除します。

<Metadata>
  ...
  <Item Key="WantsSignedAssertions">false</Item>
  <Item Key="ResponsesSigned">false</Item>
</Metadata>

暗号化された SAML 応答を要求する

すべての受信アサーションの暗号化を要求するには、 WantsEncryptedAssertions メタデータを 設定します。暗号化が必要な場合、ID プロバイダーは Azure AD B2C 技術プロファイルの暗号化証明書の公開キーを使用します。 Azure AD B2C は、暗号化証明書のプライベート部分を使用して応答アサーションを復号化します。

アサーション暗号化を有効にする場合は、応答署名の検証を無効にする必要がある場合もあります (詳細については、「署名済みの SAML 応答を要求する」を参照してください。

WantsEncryptedAssertions メタデータが true に設定されている場合、Azure AD B2C 技術プロファイルのメタデータには暗号化セクションが含まれます。 ID プロバイダーはメタデータを読み取り、Azure AD B2C 技術プロファイルのメタデータで提供される公開キーを使用して SAML 応答アサーションを暗号化します。

次の例は、暗号化に使用される SAML メタデータのキー記述子セクションを示しています。

<SPSSODescriptor AuthnRequestsSigned="true"  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <KeyDescriptor use="encryption">
    <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
      <X509Data>
        <X509Certificate>valid certificate</X509Certificate>
      </X509Data>
    </KeyInfo>
  </KeyDescriptor>
  ...
</SPSSODescriptor>

SAML 応答アサーションを暗号化するには:

一意の識別子を持つポリシーキーを作成します。たとえば、B2C_1A_SAMLEncryptionCert のようにします。
SAML 技術プロファイルのCryptographicKeysコレクションにあります。 StorageReferenceId を、最初の手順で作成したポリシーキーの名前に設定します。 SamlAssertionDecryption ID は、暗号化キーを使用して SAML 応答のアサーションを暗号化および復号化することを示します。
```
<CryptographicKeys>
        ...
  <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
</CryptographicKeys>
```
技術プロファイルメタデータ WantsEncryptedAssertions を trueに設定します。
```
<Metadata>
  ...
  <Item Key="WantsEncryptedAssertions">true</Item>
</Metadata>
```
新しい Azure AD B2C 技術プロファイルメタデータを使用して ID プロバイダーを更新します。 use プロパティが証明書の公開キーを含むに設定されている encryption が表示されます。

コンテキスト要求の使用を有効にする

入力要求と出力要求コレクションには、 DefaultValue 属性を設定している限り、ID プロバイダーから返されない要求を含めることができます。技術プロファイルに含めるコンテキスト要求を使用することもできます。コンテキスト要求を使用するには:

BuildingBlocks 内の ClaimsSchema 要素に要求の種類を追加します。
出力要求を入力または出力コレクションに追加します。次の例では、最初の要求によって ID プロバイダーの値が設定されます。 2 番目の要求では、ユーザー IP アドレスコンテキスト要求が使用されます。
```
<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" AlwaysUseDefaultValue="true" />
  <OutputClaim ClaimTypeReferenceId="IpAddress" DefaultValue="{Context:IPAddress}" AlwaysUseDefaultValue="true" />
</OutputClaims>
```

単一ログアウトを無効にする

アプリケーションのサインアウト要求時に、Azure AD B2C は SAML ID プロバイダーからのサインアウトを試みます。詳細については、 Azure AD B2C セッションのサインアウトに関するページを参照してください。単一ログアウト動作を無効にするには、 SingleLogoutEnabled メタデータを falseに設定します。

<Metadata>
  ...
  <Item Key="SingleLogoutEnabled">false</Item>
</Metadata>

SAML プロトコルのデバッグ

SAML ID プロバイダーとのフェデレーションを構成およびデバッグするには、SAML プロトコルのブラウザー拡張機能 (Chrome 用の SAML DevTools 拡張機能、Firefox 用 SAML トレーサー、 Microsoft Edge または Internet Explorer 開発者ツールなど) を使用できます。

これらのツールを使用して、Azure AD B2C と SAML ID プロバイダーの間の統合を確認できます。例えば次が挙げられます。

SAML 要求に署名が含まれているかどうかを確認し、承認要求のサインインに使用されるアルゴリズムを決定します。
AttributeStatement セクションでクレーム (アサーション) を取得します。
ID プロバイダーがエラーメッセージを返すかどうかを確認します。
アサーションセクションが暗号化されているかどうかを確認します。

SAML 要求と応答のサンプル

Security Assertion Markup Language (SAML) は、ID プロバイダーとサービスプロバイダー間で認証および認可データを交換するためのオープン標準です。 Azure AD B2C は、SAML ID プロバイダーとフェデレーションするときに、 サービスプロバイダー として機能し、SAML ID プロバイダーへの SAML 要求を開始し、SAML 応答を待機します。

成功した SAML 応答には、外部 SAML ID プロバイダーによって行われたステートメントであるセキュリティ アサーション が含まれています。 Azure AD B2C はアサーションを解析し、クレームにマップします。

承認要求

ユーザー認証を要求するために、Azure AD B2C は外部 SAML ID プロバイダーに AuthnRequest 要素を送信します。サンプルの SAML 2.0 AuthnRequest は、次の例のようになります。

<samlp:AuthnRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    ID="_11111111-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:10:00.0000000Z" 
    Destination="https://fabrikam.com/saml2" 
    ForceAuthn="false" 
    IsPassive="false" 
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
    AssertionConsumerServiceURL="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    ProviderName="https://fabrikam.com" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
</samlp:AuthnRequest>

[応答]

要求されたサインオンが正常に完了すると、外部 SAML ID プロバイダーは Azure AD B2C アサーションコンシューマーサービスエンドポイントに応答を投稿します。サインオン試行が成功した場合の応答は、次の例のようになります。

<samlp:Response 
    ID="_98765432-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T07:11:30.0000000Z" 
    Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/assertionconsumer" 
    InResponseTo="_11111111-0000-0000-0000-000000000000" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://fabrikam.com/
    </Issuer>
    <samlp:Status>
        <samlp:StatusCode 
            Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <Assertion 
        ID="_55555555-0000-0000-0000-000000000000" 
        IssueInstant="2023-03-20T07:40:45.505Z" 
        Version="2.0" 
        xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
        <Issuer>https://fabrikam.com/</Issuer>
        <Signature 
            xmlns="http://www.w3.org/2000/09/xmldsig#">
            ...
        </Signature>
        <Subject>
            <NameID 
                Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">ABCDEFG
            </NameID>
            ...
        </Subject>
        <AttributeStatement>
            <Attribute Name="uid">
                <AttributeValue>12345</AttributeValue>
            </Attribute>
            <Attribute Name="displayname">
                <AttributeValue>David</AttributeValue>
            </Attribute>
            <Attribute Name="email">
                <AttributeValue>david@contoso.com</AttributeValue>
            </Attribute>
            ....
        </AttributeStatement>
        <AuthnStatement 
            AuthnInstant="2023-03-20T07:40:45.505Z" 
            SessionIndex="_55555555-0000-0000-0000-000000000000">
            <AuthnContext>
                <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
            </AuthnContext>
        </AuthnStatement>
    </Assertion>
</samlp:Response>

ログアウト要求

アプリケーションのサインアウト要求時に、Azure AD B2C は SAML ID プロバイダーからのサインアウトを試みます。 Azure AD B2C は、セッションが終了したことを示す LogoutRequest メッセージを外部 IDP に送信します。次の抜粋は、 LogoutRequest 要素のサンプルを示しています。

NameID要素の値は、サインアウトしているユーザーのNameIDと一致します。SessionIndex要素は、サインイン SAML 応答のSessionIndexのAuthnStatement属性と一致します。

<samlp:LogoutRequest 
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    ID="_22222222-0000-0000-0000-000000000000" 
    Version="2.0" 
    IssueInstant="2023-03-20T08:21:07.3679354Z" 
    Destination="https://fabrikam.com/saml2/logout" 
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer 
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_TrustFrameworkBase
    </saml:Issuer>
    <saml:NameID>ABCDEFG</saml:NameID>
    <samlp:SessionIndex>_55555555-0000-0000-0000-000000000000</samlp:SessionIndex>
</samlp:LogoutRequest>

次のステップ

Application Insights を使用して、カスタムポリシーに関する問題を診断する方法について説明します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-05-06