次の方法で共有


Azure AD B2C に SAML アプリケーションを登録するためのオプション

重要

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

この記事では、Azure Active Directory B2C (Azure AD B2C) を Security Assertion Markup Language (SAML) アプリケーションに接続するときに使用できる構成オプションについて説明します。

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

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

SAML 応答署名を指定する

SAML メッセージの署名に使用する証明書を指定できます。 メッセージは、アプリケーションに送信された SAML 応答内の <samlp:Response> 要素です。

ポリシー キーがまだない場合は、 作成します。 次に、SAML トークン発行者技術プロファイルで SamlMessageSigning メタデータ項目を構成します。 StorageReferenceId は、ポリシー キー名を参照する必要があります。

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

署名アルゴリズム

SAML アサーションの署名に使用される署名アルゴリズムを構成できます。 指定できる値は、Sha256Sha384Sha512、および Sha1 です。 技術プロファイルとアプリケーションで同じ署名アルゴリズムが使用されていることを確認します。 証明書でサポートされているアルゴリズムのみを使用してください。

証明書利用者Metadata要素内のXmlSignatureAlgorithm メタデータ キーを使用して署名アルゴリズムを構成します。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="XmlSignatureAlgorithm">Sha256</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

SAML アサーション署名を確認する

アプリケーションで SAML アサーション セクションに署名が必要な場合は、SAML サービス プロバイダーが WantAssertionsSignedtrueに設定していることを確認します。 falseに設定されている場合、または存在しない場合、アサーション セクションは署名されません。

次の例は、 WantAssertionsSignedtrue に設定された SAML サービス プロバイダーのメタデータを示しています。

<EntityDescriptor ID="id123456789" entityID="https://samltestapp2.azurewebsites.net" validUntil="2099-12-31T23:59:59Z" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
  <SPSSODescriptor WantAssertionsSigned="true" AuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  ...
  </SPSSODescriptor>
</EntityDescriptor>

署名証明書

ポリシーでは、SAML 応答の SAML アサーション セクションに署名するために使用する証明書を指定する必要があります。 ポリシー キーがまだない場合は、 作成します。 次に、SAML トークン発行者技術プロファイルで SamlAssertionSigning メタデータ項目を構成します。 StorageReferenceId は、ポリシー キー名を参照する必要があります。

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_SamlMessageCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

SAML アサーションで暗号化を有効にする

アプリケーションで SAML アサーションが暗号化された形式であることが想定されている場合は、Azure AD B2C ポリシーで暗号化が有効になっていることを確認します。

Azure AD B2C は、サービス プロバイダーの公開キー証明書を使用して SAML アサーションを暗号化します。 次の例に示すように、 KeyDescriptoruse 値が Encryption に設定されている SAML アプリケーションのメタデータ エンドポイントに公開キーが存在する必要があります。

<KeyDescriptor use="encryption">
  <KeyInfo xmlns="https://www.w3.org/2000/09/xmldsig#">
    <X509Data>
      <X509Certificate>valid certificate</X509Certificate>
    </X509Data>
  </KeyInfo>
</KeyDescriptor>

Azure AD B2C が暗号化されたアサーションを送信できるようにするには、証明書利用者技術プロファイルWantsEncryptedAssertionメタデータ項目をtrueに設定します。 SAML アサーションの暗号化に使用されるアルゴリズムを構成することもできます。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="WantsEncryptedAssertions">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

暗号化方法

SAML アサーション データの暗号化に使用する暗号化方法を構成するには、証明書利用者内で DataEncryptionMethod メタデータ キーを設定します。 使用できる値は、 Aes256 (既定値)、 Aes192Sha512、または Aes128です。 このメタデータにより、SAML 応答内の <EncryptedData> 要素の値が制御されます。

SAML アサーション データの暗号化に使用されたキーのコピーを暗号化するための暗号化方法を構成するには、証明書利用者内で KeyEncryptionMethod メタデータ キーを設定します。 使用可能な値は次のとおりです。

  • Rsa15 (既定値): RSA 公開キー暗号化標準 (PKCS) バージョン 1.5 アルゴリズム。
  • RsaOaep: RSA Optimal Asymmetric Encryption Padding (OAEP) 暗号化アルゴリズム。

このメタデータにより、SAML 応答内の <EncryptedKey> 要素の値が制御されます。

次の例は、SAML アサーションの EncryptedAssertion セクションを示しています。 暗号化されたデータメソッドは Aes128され、暗号化されたキーメソッドは Rsa15

<saml:EncryptedAssertion>
  <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
    <dsig:KeyInfo>
      <xenc:EncryptedKey>
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
        <xenc:CipherData>
          <xenc:CipherValue>...</xenc:CipherValue>
        </xenc:CipherData>
      </xenc:EncryptedKey>
    </dsig:KeyInfo>
    <xenc:CipherData>
      <xenc:CipherValue>...</xenc:CipherValue>
    </xenc:CipherData>
  </xenc:EncryptedData>
</saml:EncryptedAssertion>

暗号化されたアサーションの形式を変更できます。 暗号化形式を構成するには、証明書利用者内で UseDetachedKeys メタデータ キーを設定します。 指定できる値: true または false(既定値)。 値が true に設定されている場合、デタッチされたキーは、暗号化されたアサーションをEncryptedDataの代わりにEncryptedAssertionの子として追加します。

証明書利用者技術プロファイル内のメタデータ キーを使用して、暗号化方法と形式を構成します。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="DataEncryptionMethod">Aes128</Item>
      <Item Key="KeyEncryptionMethod">Rsa15</Item>
      <Item Key="UseDetachedKeys">false</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

IdP によって開始されるフローを構成する

アプリケーションが最初に SAML AuthN 要求を ID プロバイダー (IdP) に送信せずに SAML アサーションを受信することを想定している場合は、IdP によって開始されるフロー用に Azure AD B2C を構成する必要があります。

IdP によって開始されるフローでは、ID プロバイダー (Azure AD B2C) がサインイン プロセスを開始します。 ID プロバイダーは、要求されていない SAML 応答をサービス プロバイダー (証明書利用者アプリケーション) に送信します。

現在、開始 ID プロバイダーが Azure AD B2C とフェデレーションされている外部 ID プロバイダー ( Active Directory フェデレーション サービスSalesforce など) であるシナリオはサポートされていません。 IdP によって開始されるフローは、Azure AD B2C のローカル アカウント認証でのみサポートされます。

IdP 開始フローを有効にするには、IdpInitiatedProfileEnabledメタデータ項目を証明書利用者技術プロファイルtrueに設定します。

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="SAML2"/>
    <Metadata>
      <Item Key="IdpInitiatedProfileEnabled">true</Item>
    </Metadata>
   ..
  </TechnicalProfile>
</RelyingParty>

IdP 開始フローを使用してユーザーがサインインまたはサインアップするには、次の URL を使用します。

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/generic/login?EntityId=<app-identifier-uri>&RelayState=<relay-state> 

次の値を置き換えます。

  • <tenant-name> を、実際のテナント名に置き換えます。
  • <policy-name>を SAML 証明書利用者ポリシーの名前に置き換えます。
  • <app-identifier-uri>をメタデータ ファイル内のidentifierUris値 (https://contoso.onmicrosoft.com/app-name など) に置き換えます。
  • [省略可能] <relay-state> を、トークン応答でも返される承認要求に含まれる値に置き換えます。 relay-state パラメーターは、認証要求が発生する前のユーザーの状態に関する情報 (ページなど) をエンコードするために使用されます。

サンプル ポリシー

SAML テスト アプリでテストするための完全なサンプル ポリシーを使用できます。

  1. SAML-SP によって開始されるログイン サンプル ポリシーをダウンロードします
  2. テナント名と一致するように TenantId を更新します。 この記事では、 contoso.b2clogin.com 例を使用します。
  3. ポリシー名は B2C_1A_signup_signin_samlのままにします。

SAML 応答の有効期間を構成する

SAML 応答が有効な期間を構成できます。 SAML トークン発行者技術プロファイル内の TokenLifeTimeInSeconds メタデータ項目を使用して有効期間を設定します。 この値は、トークン発行時に計算される、 NotBefore タイムスタンプから経過できる秒数です。 既定の有効期間は 300 秒 (5 分) です。

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenLifeTimeInSeconds">400</Item>
      </Metadata>
      ...
    </TechnicalProfile>

SAML 応答のタイム スキューを構成する

SAML 応答の NotBefore タイム スタンプに適用される時間のずれを構成できます。 この構成により、2 つのプラットフォーム間の時刻が同期されていない場合でも、SAML アサーションはこの時間のずれの範囲内にある場合でも有効と見なされます。

SAML トークン発行者の技術プロファイル内の TokenNotBeforeSkewInSeconds メタデータ項目を使用して、タイム スキューを設定します。 スキュー値は秒単位で指定され、既定値は 0 です。 最大値は 3600 (1 時間) です。

たとえば、 TokenNotBeforeSkewInSeconds120 秒に設定されている場合は、次のようになります。

  • トークンは 13:05:10 UTC に発行されます。
  • トークンは 13:03:10 UTC から有効です。
<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
      <Metadata>
        <Item Key="TokenNotBeforeSkewInSeconds">120</Item>
      </Metadata>
      ...
    </TechnicalProfile>

日付と時刻からミリ秒を削除する

SAML 応答内の日付と時刻の値からミリ秒を削除するかどうかを指定できます。 (これらの値には、 IssueInstantNotBeforeNotOnOrAfter、および AuthnInstantが含まれます)。ミリ秒を削除するには、証明書利用者内で RemoveMillisecondsFromDateTime メタデータ キーを設定します。 指定できる値: false (既定値) または true

  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
        <Item Key="RemoveMillisecondsFromDateTime">true</Item>
      </Metadata>
      <OutputClaims>
             ...
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true" />
    </TechnicalProfile>
  </RelyingParty>

発行者 ID を使用して発行者 URI をオーバーライドする

異なる entityID 値に依存する複数の SAML アプリケーションがある場合は、証明書利用者ファイルの IssuerUri 値をオーバーライドできます。 発行者 URI をオーバーライドするには、基本ファイルの Saml2AssertionIssuer ID を使用して技術プロファイルをコピーし、 IssuerUri 値をオーバーライドします。

ヒント

ベースから <ClaimsProviders> セクションをコピーし、要求プロバイダー内のこれらの要素 ( <DisplayName>Token Issuer</DisplayName><TechnicalProfile Id="Saml2AssertionIssuer"><DisplayName>Token Issuer</DisplayName>) を保持します。

例:

   <ClaimsProviders>   
    <ClaimsProvider>
      <DisplayName>Token Issuer</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Saml2AssertionIssuer">
          <DisplayName>Token Issuer</DisplayName>
          <Metadata>
            <Item Key="IssuerUri">customURI</Item>
          </Metadata>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
  </ClaimsProviders>
  <RelyingParty>
    <DefaultUserJourney ReferenceId="SignUpInSAML" />
    <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2" />
      <Metadata>
     …

セッションを管理する

UseTechnicalProfileForSessionManagement要素と SamlSSOSessionProvider を使用して、Azure AD B2C と SAML 証明書利用者アプリケーションの間のセッションを管理できます。

ユーザーに再認証を強制する

ユーザーに再認証を強制するために、アプリケーションは SAML 認証要求に ForceAuthn 属性を含めることができます。 ForceAuthn属性はブール値です。 trueに設定すると、ユーザーのセッションは Azure AD B2C で無効になり、ユーザーは強制的に再認証されます。

次の SAML 認証要求は、 ForceAuthn 属性を true に設定する方法を示しています。

<samlp:AuthnRequest 
       Destination="https://contoso.b2clogin.com/contoso.onmicrosoft.com/B2C_1A_SAML2_signup_signin/samlp/sso/login"
       ForceAuthn="true" ...>
    ...
</samlp:AuthnRequest>

Azure AD B2C IdP SAML メタデータに署名する

アプリケーションで必要な場合は、SAML ID プロバイダーのメタデータ ドキュメントに署名するように Azure AD B2C に指示できます。 ポリシー キーがまだない場合は、 作成します。 次に、SAML トークン発行者技術プロファイルで MetadataSigning メタデータ項目を構成します。 StorageReferenceId は、ポリシー キー名を参照する必要があります。

<ClaimsProvider>
  <DisplayName>Token Issuer</DisplayName>
  <TechnicalProfiles>
    <!-- SAML Token Issuer technical profile -->
    <TechnicalProfile Id="Saml2AssertionIssuer">
      <DisplayName>Token Issuer</DisplayName>
      <Protocol Name="SAML2"/>
      <OutputTokenFormat>SAML2</OutputTokenFormat>
        ...
      <CryptographicKeys>
        <Key Id="MetadataSigning" StorageReferenceId="B2C_1A_SamlMetadataCert"/>
        ...
      </CryptographicKeys>
    ...
    </TechnicalProfile>

SAML プロトコルをデバッグする

サービス プロバイダーとの統合の構成とデバッグを支援するために、SAML プロトコルのブラウザー拡張機能を使用できます。 ブラウザー拡張機能には、 Chrome 用の SAML DevTools 拡張機能Firefox 用の SAML トレーサーEdge または Internet Explorer 用の開発者ツールが含まれます。

これらのツールを使用すると、アプリケーションと Azure AD B2C の統合を確認できます。 例えば次が挙げられます。

  • SAML 要求に署名が含まれているかどうかを確認し、承認要求のサインインに使用されるアルゴリズムを決定します。
  • Azure AD B2C がエラー メッセージを返すかどうかを確認します。
  • アサーション セクションが暗号化されているかどうかを確認します。

次のステップ