Azure Active Directory B2C を使用して SAML ID プロバイダーでのサインアップとサインインを設定する

Azure Active Directory B2C (Azure AD B2C) では、SAML 2.0 ID プロバイダーとのフェデレーションがサポートされています。 この記事では、SAML ID プロバイダー ユーザー アカウントでのサインインを有効にし、ユーザーが既存のソーシャルまたはエンタープライズの ID (ADFSSalesforce など) を使用してサインインできるようにする方法について説明します。

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

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

シナリオの概要

ユーザーが外部のソーシャルまたはエンタープライズの SAML ID プロバイダー (IdP) の資格情報を使用してアプリケーションにサインインできるように、Azure AD B2C を構成できます。 Azure AD B2C が SAML ID プロバイダーとフェデレーションを行う場合、SAML ID プロバイダー への SAML 要求を開始して、SAML 応答を待機するサービス プロバイダーとして機能します。 次の図で説明します。

  1. アプリケーションが Azure AD B2C への認可要求を開始します。 このアプリケーションは、OAuth 2.0 または OpenId Connect アプリケーション、または SAML サービス プロバイダーである場合があります。
  2. Azure AD B2C のサインイン ページで、ユーザーは SAML ID プロバイダー アカウント (Contoso など) でサインインすることを選択します。 Azure AD B2C が SAML 認可要求を開始し、サインインを完了するためにユーザーを SAML ID プロバイダーに移動させます。
  3. SAML ID プロバイダーが SAML 応答を返します。
  4. Azure AD B2C では SAML トークンを検証し、要求を抽出して、独自のトークンを発行し、ユーザーをアプリケーションに戻します。

Sign in with SAML identity provider flow

前提条件

ソリューションのコンポーネント

このシナリオに必要なコンポーネントは次のとおりです。

  • Azure AD B2C から SAML 要求を受信、デコード、応答する機能を持つ SAML ID プロバイダー
  • お使いの ID プロバイダー向けに公開されている SAML メタデータ エンドポイント
  • Azure AD B2C テナント

重要

エンドポイントは、Azure AD B2C のセキュリティ要件に準拠している必要があります。 以前の TLS バージョンと暗号は非推奨です。 詳細については、Azure AD B2C の TLS および暗号スイートの要件に関するページを参照してください。

ポリシー キーを作成する

Azure AD B2C と SAML ID プロバイダー間の信頼関係を確立するには、有効な X509 証明書と秘密キーを提供する必要があります。 Azure AD B2C は、証明書の秘密キーを使用して SAML 要求に署名します。 ID プロバイダーは、証明書の公開キーを使用して要求を検証します。 公開キーには、技術プロファイル メタデータを介してアクセスできます。 代わりに、.cer ファイルを SAML ID プロバイダーに手動でアップロードすることもできます。

自己署名証明書は、ほとんどのシナリオで受け入れ可能です。 運用環境では、証明機関が発行した X509 証明書を使用することをお勧めします。 また、このドキュメントの後半で説明する、非運用環境に無効では、両側で SAML の署名を無効にできます。

証明書を取得する

証明書をまだ持っていない場合は、自己署名証明書を使用できます。 自己署名証明書は、証明機関 (CA) によって署名されていないセキュリティ証明書であり、CA によって署名された証明書のセキュリティ保証を提供するものではありません。

Windows では、PowerShell の New-SelfSignedCertificate コマンドレットを使用して証明書を生成します。

  1. この PowerShell コマンドを実行して、自己署名証明書を生成します。 contosowebapp.contoso.onmicrosoft.com などのアプリケーションと Azure AD B2C のテナント名に合わせて -Subject 引数を変更します。 また、証明書に別の有効期限を指定するように -NotAfter 日付を調整することもできます。

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. Windows コンピューターで、 [ユーザー証明書の管理] を検索して選択します

  3. [証明書 - 現在のユーザー] で、[個人用][証明書]yourappname.yourtenant.onmicrosoft.com を開きます。

  4. 証明書を選択し、[アクション][すべてのタスク][エクスポート] の順に選択します。

  5. [次へ][はい、秘密キーをエクスポートします][次へ] を選択します。

  6. [エクスポート ファイルの形式] の既定値を受け入れて、 [次へ] を選択します。

  7. [パスワード] オプションを有効にして、証明書のパスワードを入力し、 [次へ] を選択します。

  8. 証明書を保存する場所を指定するには、 [参照] を選択し、任意のディレクトリに移動します。

  9. [名前を付けて保存] ウィンドウで、 [ファイル名] を入力して、 [保存] を選択します。

  10. [次へ][完了] の順に選択します。

Azure AD B2C で .pfx ファイルのパスワードを受け入れるには、Windows 証明書ストアのエクスポート ユーティリティで、AES256-SHA256 ではなく、TripleDES-SHA1 オプションを使用してパスワードを暗号化する必要があります。

証明書をアップロードする

証明書を Azure AD B2C テナントに格納する必要があります。

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions]\(ディレクトリ + サブスクリプション\) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions]\(ディレクトリ + サブスクリプション\) ページで Azure AD B2C ディレクトリを [ディレクトリ名] リストで見つけ、 [Switch] を選択します。
  4. Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
  5. [概要] ページで、 [Identity Experience Framework] を選択します。
  6. [ポリシー キー] を選択し、 [追加] を選択します。
  7. オプションについては、を選択します。
  8. ポリシー キーの名前を入力します。 たとえば、「 SAMLSigningCert 」のように入力します。 プレフィックス B2C_1A_ がキーの名前に自動的に追加されます。
  9. 秘密キーが含まれている証明書の .pfx ファイルを参照して選択します。
  10. Create をクリックしてください。

SAML 技術プロファイルを構成する

SAML ID プロバイダーを定義するには、それをポリシーの拡張ファイル内の ClaimsProviders 要素に追加します。 クレーム プロバイダーには、SAML ID プロバイダーと通信するために必要なエンドポイントとプロトコルを決定する SAML 技術プロファイルが含まれています。 SAML 技術プロファイルを持つクレーム プロバイダーを追加するには、次のようにします。

  1. TrustFrameworkExtensions.xml を開きます。

  2. ClaimsProviders 要素を見つけます。 存在しない場合は、それをルート要素の下に追加します。

  3. 新しい ClaimsProvider を次のように追加します。

    <ClaimsProvider>
      <Domain>Contoso.com</Domain>
      <DisplayName>Contoso</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="Contoso-SAML2">
          <DisplayName>Contoso</DisplayName>
          <Description>Login with your SAML identity provider account</Description>
          <Protocol Name="SAML2"/>
          <Metadata>
            <Item Key="PartnerEntity">https://your-AD-FS-domain/federationmetadata/2007-06/federationmetadata.xml</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_SAMLSigningCert"/>
          </CryptographicKeys>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="assertionSubjectName" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="last_name" />
            <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="http://schemas.microsoft.com/identity/claims/displayname" />
            <OutputClaim ClaimTypeReferenceId="email"  />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="contoso.com" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/>
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/>
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/>
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/>
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-idp"/>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    

関連する値を使用して、次の XML 要素を更新します。

XML 要素
ClaimsProvider\Domain 直接サインインに使用するドメイン名。 直接サインインに使用するドメイン名を入力します。 たとえば、Contoso.com などです
TechnicalProfile\DisplayName この値は、サインイン画面のサインイン ボタン上に表示されます。 たとえば、Contoso です。
Metadata\PartnerEntity SAML ID プロバイダーのメタデータの URL です。 または、ID プロバイダーのメタデータをコピーし、CDATA 要素 <![CDATA[Your IDP metadata]]> 内に追加します。

要求をマップする

OutputClaims 要素には、SAML ID プロバイダーにより返される要求の一覧が存在します。 お使いのポリシーに定義されている要求の名前を、ID プロバイダーで定義されているアサーション名にマップします。 要求 (アサーション) の一覧については、お使いの ID プロバイダーを確認してください。 詳細については、要求のマッピングに関する記事を参照してください。

上の例では、Contoso-SAML2 には、SAML ID プロバイダーから返された要求が含まれています。

  • issuerUserId 要求は、assertionSubjectName 要求にマップされます。
  • givenName 要求にマップされている first_name 要求。
  • surname 要求にマップされている last_name 要求。
  • displayName 要求は、 要求にマップされます。
  • どの名前にもマップされていない email 要求。

また、技術プロファイルは、ID プロバイダーにより返されない要求も返します。

  • ID プロバイダーの名前を保持する identityProvider 要求。
  • 既定値の socialIdpAuthentication である authenticationSource 要求。

SAML セッション技術プロファイルを追加する

まだ SM-Saml-idp SAML セッション技術プロファイルがない場合は、お使いの拡張ポリシーに追加します。 <ClaimsProviders> セクションを見つけて、次の XML スニペットを追加します。 ポリシーに SM-Saml-idp 技術プロファイルが既に含まれている場合、次の手順に進みます。 詳細については、シングル サインオン セッション管理に関するページを参照してください。

<ClaimsProvider>
  <DisplayName>Session Management</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SM-Saml-idp">
      <DisplayName>Session Management Provider</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <Item Key="IncludeSessionIndex">false</Item>
        <Item Key="RegisterServiceProviders">false</Item>
      </Metadata>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

ユーザー体験を追加する

この時点では、ID プロバイダーはセットアップされていますが、サインイン ページではまだ使用できません。 独自のカスタム ユーザー体験がない場合は、既存のテンプレート ユーザー体験の複製を作成してください。そうでない場合は、次の手順に進みます。

  1. スターター パックから TrustFrameworkBase.xml ファイルを開きます。
  2. を含む UserJourney 要素を見つけ、その内容全体をコピーします。
  3. TrustFrameworkExtensions.xml を開き、UserJourneys 要素を見つけます。 要素が存在しない場合は追加します。
  4. コピーした UserJourney 要素の内容全体を UserJourneys 要素の子として貼り付けます。
  5. ユーザー体験の ID の名前を変更します。 たとえば、「 Id="CustomSignUpSignIn" 」のように入力します。

ユーザー体験に ID プロバイダーを追加する

これでユーザー体験ができたので、ユーザー体験に新しい ID プロバイダーを追加します。 最初にサインイン ボタンを追加してから、ボタンをアクションにリンクします。 アクションは、前に作成した技術プロファイルです。

  1. ユーザー体験内で、Type="CombinedSignInAndSignUp" または Type="ClaimsProviderSelection" を含むオーケストレーション ステップ要素を見つけます。 これは通常、最初のオーケストレーション ステップです。 ClaimsProviderSelections 要素には、ユーザーがサインインに使用できる ID プロバイダーの一覧が含まれています。 要素の順序により、ユーザーに表示されるサインイン ボタンの順序が制御されます。 ClaimsProviderSelection XML 要素を追加します。 TargetClaimsExchangeId の値をフレンドリ名に設定します。

  2. 次のオーケストレーション ステップで、ClaimsExchange 要素を追加します。 ID を、ターゲットの要求交換 ID の値に設定します。TechnicalProfileReferenceId の値を、前に作成した技術プロファイルの ID に更新します。

次の XML は、ID プロバイダーを使用したユーザー体験の最初の 2 つのオーケストレーション ステップを示しています。

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="ContosoExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="ContosoExchange" TechnicalProfileReferenceId="Contoso-SAML2" />
  </ClaimsExchanges>
</OrchestrationStep>

証明書利用者ポリシーを構成する

証明書利用者ポリシー (例 SignUpSignIn.xml) は、Azure AD B2C が実行されるユーザー体験を指定します。 証明書利用者内の DefaultUserJourney 要素を検索します。 ID プロバイダーを追加したユーザー体験 ID と一致するように ReferenceId を更新します。

次の例では、CustomSignUpOrSignIn ユーザー体験について、CustomSignUpOrSignInCustomSignUpOrSignIn に設定しています。

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

カスタム ポリシーをアップロードする

  1. Azure portal にサインインします。
  2. ポータル ツール バーにある [ディレクトリ + サブスクリプション] アイコンを選択し、Azure AD B2C テナントを含むディレクトリを選択します。
  3. Azure portal で、 [Azure AD B2C] を検索して選択します。
  4. [ポリシー][Identity Experience Framework] を選択します。
  5. [カスタム ポリシーのアップロード] を選択し、変更した 2 つのポリシー ファイルを拡張ポリシー ( など)、証明書利用者ポリシー (SignUpSignIn.xmlなど) の順序でアップロードします。

SAML ID プロバイダーを構成する

ポリシーを構成したら、Azure AD B2C SAML メタデータを使用して SAML ID プロバイダーを構成する必要があります。 SAML メタデータは、ポリシー (サービス プロバイダー)の構成を公開するために SAML プロトコルで使用される情報です。 それは、サインインとサインアウト、証明書、サインイン方法など、サービスの場所を定義します。

SAML ID プロバイダーごとに、サービス プロバイダーを設定する手順が異なります。 SAML ID プロバイダーによっては、Azure AD B2C メタデータを要求するものもあれば、ユーザーがメタデータ ファイルを手動で調べて情報を提供する必要があるものもあります。 ガイダンスについては、ID プロバイダーのドキュメントを参照してください。

次の例は、Azure AD B2C 技術プロファイルの SAML メタデータの URL アドレスを示しています。

https://<your-tenant-name>.b2clogin.com/<your-tenant-name>.onmicrosoft.com/<your-policy>/samlp/metadata?idptp=<your-technical-profile>

カスタム ドメインを使用する場合は、次の形式を使用します。

https://your-domain-name/<your-tenant-name>.onmicrosoft.com/<your-policy>/samlp/metadata?idptp=<your-technical-profile>

次の値を置き換えます。

  • your-tenant-name を実際のテナント名 (your-tenant.onmicrosoft.com など) に。
  • your-domain-name を実際のカスタム ドメイン名 (login.contoso.com) に。
  • your-policy は、実際のポリシー名に置き換えます。 たとえば、「B2C_1A_signup_signin_adfs」とします。
  • your-technical-profile は、お使いの SAML ID プロバイダー技術プロファイルの名前に置き換えます。 たとえば、「Contoso-SAML2」とします。

ブラウザーを開き、この URL に移動します。 正しい URL を入力し、XML メタデータ ファイルにアクセスできることを確認します。

カスタム ポリシーのテスト

  1. Azure portal にサインインします。
  2. ご自分の Azure AD B2C テナントが含まれるディレクトリを必ず使用してください。 ポータル ツールバーの [Directories + subscriptions]\(ディレクトリ + サブスクリプション\) アイコンを選択します。
  3. [ポータルの設定] | [Directories + subscriptions]\(ディレクトリ + サブスクリプション\) ページの [ディレクトリ名] の一覧で自分の Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。
  4. Azure portal で、 [Azure AD B2C] を検索して選択します。
  5. [ポリシー][Identity Experience Framework] を選択します。
  6. 証明書利用者ポリシー (B2C_1A_signup_signin など) を選択します。
  7. [アプリケーション] には、前に登録した Web アプリケーションを選択します。 [応答 URL] と表示されます。
  8. [今すぐ実行] ボタンを選択します。
  9. サインアップまたはサインイン ページで、 [Contoso] を選択し、Contoso アカウントでサインインします。

サインイン プロセスが成功すると、ブラウザーは https://jwt.ms にリダイレクトされ、Azure AD B2C によって返されたトークンの内容が表示されます。

次のステップ