チュートリアル: Azure Active Directory B2C を使用して IDEMIA Mobile ID を構成する

開始する前に

Azure Active Directory B2C (Azure AD B2C) には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザー フローを使用する、または構成可能なカスタム ポリシーを使用する) があります。 「ユーザー フローとカスタム ポリシーの概要」を参照してください。

Azure AD B2C と IDEMIA Mobile ID を統合する

IDEMIA では、不正行為や資格情報の再利用などを削減する、顔 ID や指紋のような生体認証サービスを提供しています。 Mobile ID を使用すると、物理 ID の補完に役立つ、政府発行の信頼できるデジタル ID の恩恵を受けることができます。 Mobile ID は、自己選択の PIN、タッチ ID、または顔 ID を使用して ID を検証します。 ユーザーは、トランザクションに必要な情報を共有することで、ID を制御します。 多くの州の自動車管理局 (DMV) で、Mobile ID が使用されています。

詳細については、idemia.com で IDEMIA の情報を参照してください。

シナリオの説明

Mobile ID 統合には、次のコンポーネントが含まれています。

  • Azure AD B2C - ユーザー資格情報を検証する承認サーバー。
    • ID プロバイダー (IdP) とも呼ばれます。
  • IDEMIA Mobile ID - Azure AD B2C 外部プロバイダーとして構成された OpenID Connect (OIDC) プロバイダー
  • IDEMIA Mobile ID アプリケーション - 運転免許証や国から発行される ID のデジタル版で、スマートフォンのアプリに存在します

Mobile ID は、デジタル化された ID ドキュメントであり、DMV が個々の ID を検証するために使用するポータブル モバイル ID トークンです。 署名済みのデジタル化された ID は、エッジ上の ID としてユーザーの携帯電話に格納されます。 署名された資格情報を使用すると、年齢証明、財務取引における本人確認、アカウント アクセスなど、ID サービスへのアクセスが容易になります。

次の図は、Mobile ID を使用したサインアップとサインインのユーザー フローを示しています。

Mobile ID を使用したサインアップおよびサインインのユーザー フローの図。

  1. ユーザーは、デバイスと Mobile ID を使用して Azure AD B2C サインイン ページ (応答側) にアクセスしてトランザクションを実行します。
  2. Azure AD B2C は ID チェックを実行します。 OIDC 認証コード フローを使用して IDEMIA ルーターにユーザーをリダイレクトします。
  3. このルーターは、認証および承認のリクエスト詳細と一緒に、生体認証チャレンジをユーザーのモバイル アプリに送信します。
  4. セキュリティによっては、PIN の入力、自撮り、またはその両方など、詳細を入力するように求められる場合があります。
  5. 認証応答では、所有、存在、同意の証明を提供します。 応答はルーターに戻されます。
  6. ルーターはユーザー情報を検証し、その結果とともに Azure AD B2C に応答します。
  7. ユーザーは、アクセスを許可/拒否されます。

Mobile ID を有効にする

作業を開始するには、idemia.com の「Get in touch」ページに移動して、デモを要求します。 要求フォームのテキスト フィールドで、Azure AD B2C 統合に関心があることを記入します。

Mobile ID と Azure AD B2C の統合

次のセクションに従って、統合プロセスの準備を行い、実行します。

前提条件

開始するには、以下が必要です。

  • IDEMIA、米国の州が発行したモバイル ID 資格情報 (mID) を持つユーザーへのアクセス

    • テスト フェーズ中の場合、IDEMIA からの mID デモ アプリケーション
  • Azure サブスクリプション

  • Azure サブスクリプションにリンクされている Azure AD B2C テナント

  • Azure AD B2C テナントに登録されているビジネス Web アプリケーション

    • テスト中の場合、https://jwt.ms (デコードされたトークン コンテンツを含む Microsoft Web アプリケーション) を構成します

    Note

    トークンの内容がブラウザーから別の場所に送信されることはありません。

mID の証明書利用者アプリケーションを送信する

Mobile ID の統合中に、次の情報が提供されます。

プロパティ 説明
アプリケーション名 Azure AD B2C または別のアプリケーション名
Client_ID ID プロバイダー (IdP) からの一意の識別子
クライアント シークレット IDEMIA IdP での認証に使用される証明書利用者アプリケーションのパスワード
メタデータ エンドポイント トークン発行者の構成ドキュメントを指す URL (OpenID の既知の構成エンドポイントとも呼ばれます)。
リダイレクト URI https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp
たとえば、https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp のように指定します。

カスタム ドメインを使用する場合は、「https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp」と入力します。
サインアウト後のリダイレクト URI https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout
サインアウト要求を送信します。

Note

クライアント ID とクライアント シークレットは、後で Azure AD B2C の IdP を構成するときに必要になります。

ポリシー キーを作成する

Azure AD B2C テナントに、メモした IDEMIA クライアント シークレットを格納します。 次の手順では、Azure AD B2C テナントでディレクトリを使用します。

  1. Azure portal にサインインします。
  2. ポータルのツール バーで、[ディレクトリとサブスクリプション] を選択します。
  3. [ポータルの設定] の [ディレクトリとサブスクリプション] ページにある [ディレクトリ名] リストで、自分の Azure AD B2C ディレクトリを見つけます。
  4. [切り替え] を選択します。
  5. Azure portal の左上にある [すべてのサービス] を選択します。
  6. Azure AD B2C を検索して選択します。
  7. [概要] ページで、 [Identity Experience Framework] を選択します。
  8. [ポリシー キー] を選択します。
  9. [追加] を選択します。
  10. [オプション] では、 [手動] を選びます。
  11. ポリシー キーの名前を入力します。 たとえば、「 IdemiaAppSecret 」のように入力します。 プレフィックス B2C_1A_ がキー名に追加されます。
  12. [シークレット] に、メモしたクライアント シークレットを入力します。
  13. キー使用法には [署名] を選択します。
  14. [作成] を選択します

Mobile ID を外部 IdP として構成する

ユーザーが Mobile ID でサインインできるようにするには、IDEMIA をクレーム プロバイダーとして定義します。 このアクションにより、Azure AD B2C がエンドポイントを介して通信するようになります。また、Azure AD B2C が生体認証でユーザー認証を検証するために使用するクレームが提供されます。

IDEMIA をクレーム プロバイダーとして定義するには、ポリシー拡張ファイルの ClaimsProvider 要素に IDEMIA を追加します。

     <TechnicalProfile Id="Idemia-Oauth2">
          <DisplayName>IDEMIA</DisplayName>
          <Description>Login with your IDEMIA identity</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="METADATA">https://idp.XXXX.net/oxauth/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid id_basic mt_scope</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="token_endpoint_auth_method">client_secret_basic</Item>
            <Item Key="ClaimsEndpoint">https://idp.XXXX.net/oxauth/restv1/userinfo</Item>
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_IdemiaAppSecret" />
</CryptographicKeys>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr_values" DefaultValue="loa-2" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName1" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="lastName1" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="idemia" />
            <OutputClaim ClaimTypeReferenceId="documentId" />
            <OutputClaim ClaimTypeReferenceId="address1" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
           

client_id を、アプリケーションの登録で取得したアプリケーション ID に設定します。

プロパティ 説明
Scope OpenID Connect (OIDC) では、少なくとも scope パラメーターを openid に設定する必要があります。 スペース区切りのリストとして、さらにスコープを追加します。
redirect_uri これは、ユーザー エージェントが Azure AD B2C に認証コードを送信する場所になります。
response_type 認証コードのフローでは、[コード] を選択します。
acr_values 認証中にユーザーが実行すべき認証方法は、このパラメーターによって制御されます。

次のいずれかの値を選択します。

パラメーター値 ユーザー認証プロセスへの影響
loa-2 暗号化ベースの Microsoft Entra 多要素認証のみ
loa-3 暗号化ベースの MFA に加えて、もう 1 つの要素
loa-4 暗号化ベースの MFA に加えて、ユーザーが PIN と生体認証を実行する

/Userinfoエンドポイントは、承認要求で要求されたスコープの要求を提供します。 <mt_scope> の場合、姓、名、運転免許証番号などのクレームが含まれます。 スコープのクレーム セットは、検出 API の scope_to_claims_mapping セクションで公開されます。 Azure AD B2C は、クレーム エンドポイントにクレームを要求し、それらを OutputClaims 要素で返します。 ポリシーのクレーム名を IdP の名前にマップする必要がある場合があります。 ClaimSchema 要素でクレームの種類を定義します。

<ClaimType Id="documentId">
     <DisplayName>documentId</DisplayName>
     <DataType>string</DataType>
</ClaimType>
<ClaimType Id="address1">
     <DisplayName>address</DisplayName>
     <DataType>string</DataType>
</ClaimType>

ユーザー体験を追加する

これらの手順では、IdP は設定されていますが、サインイン ページには表示されません。 カスタム ユーザー体験がない場合は、テンプレート ユーザー体験をコピーします。

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

ユーザー体験に IdP を追加する

ユーザー体験がある場合は、新しい IdP を追加します。 最初にサインイン ボタンを追加してから、それを作成した技術プロファイルのアクションにリンクします。

  1. ユーザー体験で、Type=CombinedSignInAndSignUp または Type=ClaimsProviderSelection を含むオーケストレーション ステップ要素を見つけます。 これは通常、最初のオーケストレーション ステップです。 ClaimsProviderSelections 要素には、ユーザーがサインインする IdP リストがあります。 要素の順序により、ユーザーに表示されるサインイン ボタンの順序が制御されます。
  2. ClaimsProviderSelection XML 要素を追加します。
  3. TargetClaimsExchangeId の値をフレンドリ名に設定します。
  4. ClaimsExchange 要素を追加します。
  5. Id を、ターゲットの要求交換 ID の値に設定します。
  6. TechnicalProfileReferenceId の値を、作成した技術プロファイルの ID に更新します。

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

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

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="IdemiaExchange" TechnicalProfileReferenceId="Idemia-Oauth2" />
  </ClaimsExchanges>
</OrchestrationStep>

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

証明書利用者ポリシー (例: SignUpSignIn.xml) は、Azure AD B2C が実行するユーザー体験を指定します。

  1. 証明書利用者の DefaultUserJourney 要素を見つけます。
  2. IdP を追加したユーザー体験 ID と一致するように ReferenceId を更新します。

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

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

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

次の手順では、Azure AD B2C テナントでディレクトリを使用します。

  1. Azure portal にサインインします。

  2. ポータルのツール バーで、[ディレクトリとサブスクリプション] を選択します。

  3. [ポータルの設定]、[ディレクトリとサブスクリプション] ページの [ディレクトリ名] リストで、自分の Azure AD B2C ディレクトリを見つけます。

  4. [切り替え] を選択します。

  5. Azure portal で、 [Azure AD B2C] を検索して選択します。

  6. [ポリシー][Identity Experience Framework] を選択します。

  7. [カスタム ポリシーのアップロード] を選択します。

  8. 次の順序で、変更した 2 つのポリシー ファイルをアップロードします。

    • 拡張機能ポリシー (TrustFrameworkExtensions.xml など)
    • 証明書利用者ポリシー (SignUpSignIn.xml など)

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

  1. 証明書利用者ポリシー (B2C_1A_signup_signin など) を選択します。
  2. [アプリケーション] で、登録した Web アプリケーションを選択します。
  3. https://jwt.ms[応答 URL] に表示されます。
  4. [今すぐ実行] を選択します。
  5. サインアップまたはサインイン ページで、[IDEMIA] を選択します。
  6. ブラウザーは https://jwt.ms にリダイレクトされます。 Azure AD B2C によって返されるトークンの内容を確認します。

詳細については、「チュートリアル: Azure AD B2C に Web アプリケーションを登録する」を参照してください。

次のステップ