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

  • [アーティクル]

この記事では、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 アサーションの署名に使用される署名アルゴリズムを構成できます。 指定できる値は、Sha256、Sha384、Sha512、および 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 サービス プロバイダーで WantAssertionsSigned が true に設定されていることを確認します。 これが false に設定されている場合、または存在しない場合、アサーション セクションは署名されません。

次の例は、WantAssertionsSigned が true に設定された 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 (既定値)、Aes192、Sha512、または Aes128 です。 このメタデータにより、SAML 応答内の <EncryptedData> 要素の値が制御されます。

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

  • Rsa15 (既定値): RSA 公開キー暗号化標準 (PKCS) バージョン 1.5 アルゴリズム。
  • RsaOaep: RSA 最適非対称暗号化パディング (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 Initiated フローを構成する

対象のアプリケーションで、SAML AuthN 要求を最初に ID プロバイダー (IdP) に送信することなく SAML アサーションを受け取ることを想定している場合は、IdP Initiated フロー用に Azure AD B2C を構成する必要があります。

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

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

IdP Initiated フローを有効にするには、証明書利用者の技術プロファイル内で、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 Initiated フローを通じてユーザーをサインインまたはサインアップするには、次の 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 時間) です。

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

  • トークンが 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 応答内の日付と時刻の値からミリ秒を削除するかどうかを指定できます (これらの値には、IssueInstant、NotBefore、NotOnOrAfter、および 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 をオーバーライドするには、基本ファイルから ID が Saml2AssertionIssuer の技術プロファイルをコピーし、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 メタデータに署名する

アプリケーションで必要な場合は、Azure AD B2C に対して、SAML ID プロバイダーのメタデータ ドキュメントに署名するように指示できます。 まだポリシー キーがない場合は、作成します。 次に、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-tracer、および Edge または Internet Explorer 用の開発者ツールがあります。

これらのツールを使用すると、対象のアプリケーションと Azure AD B2C の統合を確認できます。 次に例を示します。

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

次のステップ