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

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 を正規化された要求として読み取るには、要求 PartnerClaimTypeSPNameQualifier 属性の値に設定します。 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" />

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

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

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

2 つのバインドを持つ Azure AD メタデータ シングル サインオン サービスの例を次に示します。 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>

Assertion Consumer Service

Assertion Consumer Service (または 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 の基本ポリシーとなります。

Azure AD B2C ポリシー メタデータの Assertion Consumer Service 要素の例を次に示します。

<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 要求署名を無効にするには、WantsSignedRequestsfalse に設定します。 メタデータが false に設定されている場合、SigAlgSignature パラメーター (クエリ文字列または post パラメーター) は要求から省略されます。

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

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

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

署名アルゴリズム

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

キー情報を含める

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

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

SAML 要求名 ID を構成する

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

推奨ユーザー名

サインインのユーザー体験中に、証明書利用者アプリケーションが特定のユーザーをターゲットとする可能性があります。 Azure AD B2C を使用すると、適切なユーザー名を SAML ID プロバイダーに送信できます。 InputClaims 要素は、SAML 認可要求の Subject 内で NameId を送信するために使用されます。

認可要求内にサブジェクト名 ID を含めるには、<CryptographicKeys> の直後に次の <InputClaims> 要素を追加します。 PartnerClaimTypesubject に設定されている必要があります。

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

この例では、Azure AD B2C により、SAML 認可要求の Subject 内に 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 プロバイダーのドキュメントを参照してください。 次に、対応するポリシー形式で 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 ポリシーの形式を指定する場合は、NameIDPolicyAllowCreate プロパティを指定して、サインイン フロー中に新しいアカウントを作成することが ID プロバイダーに許可されているかどうかを示すこともできます。 ガイダンスについては、ID プロバイダーのドキュメントを参照してください。

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

次の例は、NameIDPolicyAllowCreate プロパティを 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 に設定されます。 メタデータ項目を下のように設定すると、外部 IDP に対するすべての要求で、この値の使用を強制できます。

次の例では ForceAuthN プロパティを true に設定します。

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

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

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

プロバイダー名

必要に応じて、SAML 承認要求に ProviderName 属性を含めることができます。 次に示すようにメタデータ項目を設定して、外部 SAML IDP へのすべての要求にプロバイダー名を含めます。 次の例では 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 メタデータを追加します。 値に、認証コンテキスト クラスを識別する URI 参照を 1 つ以上指定します。 複数の 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 BC と 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 では、すべての受信アサーションが署名されている必要があります。 この要件を削除するには、WantsSignedAssertionsfalse に設定します。 この場合、ID プロバイダーによってアサーションは署名されませんが、署名された場合でも、Azure AD B2C によって署名は検証されません。

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

<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 技術プロファイルのメタデータには encryption セクションが含まれます。 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 応答のアサーションを暗号化する場合:

  1. 一意の識別子を使用してポリシー キーを作成します。 たとえば、「 B2C_1A_SAMLEncryptionCert 」のように入力します。

  2. SAML 技術プロファイルの CryptographicKeys コレクションで、 StorageReferenceId を、最初の手順で作成したポリシー キーの名前に設定します。 SamlAssertionDecryption ID は、暗号化キーを使用して、SAML 応答のアサーションを暗号化および復号化することを示します。

    <CryptographicKeys>
            ...
      <Key Id="SamlAssertionDecryption" StorageReferenceId="B2C_1A_SAMLEncryptionCert"/>
    </CryptographicKeys>
    
  3. 技術プロファイル メタデータ WantsEncryptedAssertionstrue に設定します。

    <Metadata>
      ...
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
    
  4. ID プロバイダーを新しい Azure AD B2C の技術プロファイルのメタデータで更新します。 use プロパティ付きの KeyDescriptor が証明書の公開キーを含む encryption に設定されます。

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

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

  1. BuildingBlocks 内の ClaimsSchema 要素に要求の種類を追加します。

  2. 入力または出力のコレクションに出力要求を追加します。 次の例では、最初の要求で 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 トレーサーEdge または IE 開発者ツールなどです。

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

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

次の手順

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