多要素認証用に Azure Active Directory B2C を使用して Asignio を構成する

重要

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

Microsoft Entra ID (Azure AD B2C) 認証を Asignio と統合する方法について説明します。この統合により、パスワードレス、ソフト生体認証、多要素認証エクスペリエンスをお客様に提供します。 Asignio は、ユーザー認証に特許を取得した Asignio Signature とライブ顔認証を使用します。変更可能な生体認証署名は、オムニチャネル認証を通じてパスワード、詐欺、フィッシング、資格情報の再利用を減らすのに役立ちます。

開始する前に

ポリシーの種類セレクターを選択して、ポリシーの種類の設定を示します。 Azure AD B2C には、ユーザーがアプリケーションと対話する方法を定義する 2 つの方法があります。

定義済みのユーザーフロー
構成可能なカスタムポリシー

この記事の手順は、メソッドごとに異なります。

詳細情報：

[前提条件]

Azure サブスクリプション。
お持ちでない場合は、Azure 無料アカウントを入手してください

Azure サブスクリプションにリンクされた Azure AD B2C テナント
「チュートリアル: Azure Active Directory B2C テナントを作成する」を参照してください
Asignio によって発行された Asignio クライアント ID とクライアントシークレット。
これらのトークンは、モバイルまたは Web アプリケーションを Asignio に登録することによって取得されます。

カスタムポリシーの場合

チュートリアルの完了 : Azure AD B2C でユーザーフローとカスタムポリシーを作成する

シナリオの説明

この統合には、次のコンポーネントが含まれます。

Azure AD B2C - ユーザー資格情報を検証する承認サーバー
Web またはモバイルアプリケーション - Asignio MFA を使用してセキュリティで保護する
Asignio Web アプリケーション - ユーザータッチデバイス上の署名生体認証コレクション

次の図は、実装を示しています。

実装アーキテクチャを示す図。

ユーザーがモバイルまたは Web アプリケーションで Azure AD B2C サインインページを開き、サインインまたはサインアップします。
Azure AD B2C は、OpenID Connect (OIDC) 要求を使用してユーザーを Asignio にリダイレクトします。
ユーザーは生体認証サインインのために Asignio Web アプリケーションにリダイレクトされます。ユーザーがAsignio署名を登録していない場合は、SMS One-Time-Password(OTP)を使用して認証できます。認証後、ユーザーは登録リンクを受け取り、Asignio Signature を作成します。
ユーザーは、Asignio Signature と顔認証、または音声と顔の検証を使用して認証します。
チャレンジレスポンスはAsignioに送信されます。
Asignio は、Azure AD B2C サインインに対する OIDC 応答を返します。
Azure AD B2C は、認証データの受信を確認するために認証検証要求を Asignio に送信します。
ユーザーは、アプリケーションへのアクセスを許可または拒否されます。

Asignio を使用してアプリケーションを構成する

Asignio を使用してアプリケーションを構成するには、Asignio パートナー管理サイトを使用します。

組織へのアクセスを要求するには、 Asignio パートナー管理ページ asignio.com 移動します。
資格情報を使用して、Asignio Partner Administration にサインインします。
Azure AD B2C テナントを使用して、Azure AD B2C アプリケーションのレコードを作成します。 Asignio で Azure AD B2C を使用する場合、Azure AD B2C は接続されたアプリケーションを管理します。 Asignio アプリは、Azure portal のアプリを表します。
Asignio パートナー管理サイトで、クライアント ID とクライアントシークレットを生成します。
クライアント ID とクライアントシークレットをメモして格納します。これらは後で使用します。 Asignio はクライアントシークレットを格納しません。
認証後にユーザーが返されるサイトに、リダイレクト URI を入力してください。次の URI パターンを使用します。

[https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp]。

会社のロゴをアップロードします。ユーザーがサインインすると、Asignio 認証に表示されます。

Azure AD B2C に Web アプリケーションを登録する

管理するテナントにアプリケーションを登録すると、アプリケーションは Azure AD B2C と対話できます。

詳細情報: Active Directory B2C で使用できるアプリケーションの種類

このチュートリアルでは、 https://jwt.msを登録します。これは、ブラウザーから離れないデコードされたトークンコンテンツを含む Microsoft Web アプリケーションです。

Web アプリケーションを登録する

チュートリアル: Azure Active Directory B2C への Web アプリケーションの登録に関する記事の手順を完了します。

Azure AD B2C で ID プロバイダーとして Asignio を構成する

次の手順では、Azure サブスクリプションで Microsoft Entra テナントを使用します。

Azure AD B2C テナントの少なくとも B2C IEF ポリシー管理者として Azure portal にサインインします。
Azure portal のツールバーで、[ ディレクトリとサブスクリプション] を選択します。
ポータルの設定 |ディレクトリとサブスクリプションのディレクトリ名の一覧で、Microsoft Entra ディレクトリを見つけます。
[切り替え] を選択します。
Azure portal の左上隅にある [ すべてのサービス] を選択します。
Azure AD B2C を検索して選択します。
Azure portal で、 [Azure AD B2C] を検索して選択します。
左側のメニューで、[ ID プロバイダー] を選択します。
[新しい OpenID Connect プロバイダー] を選択します。
ID プロバイダーの種類>OpenID Connect を選択します。
[名前] に、Asignio サインインまたは選択した名前を入力します。
[ メタデータ URL] に「 https://authorization.asignio.com/.well-known/openid-configuration」と入力します。
[クライアント ID] に、生成したクライアント ID を入力します。
[クライアントシークレット] に、生成したクライアントシークレットを入力します。
[スコープ] には、openid 電子メールプロファイルを使用します。
応答の種類には、コードを使用します。
応答モードでは、クエリを使用します。
ドメインヒントの場合は、 https://asignio.comを使用します。
[OK] を選択.
[ この ID プロバイダーの要求をマップする] を選択します。
ユーザー ID には sub を使用します。
[表示名] には名前を使用します。
[指定された名前]には、given_nameを使用します。
姓の場合は、family_nameを使用します。
Email の場合は、電子メールを使用します。
保存を選択します。

ユーザーフローポリシーを作成する

Azure AD B2C テナントの [ ポリシー] で、[ ユーザーフロー] を選択します。
[ 新しいユーザーフロー] を選択します。
サインアップとサインインのユーザーフローの種類を選択します。
推奨 されるバージョンを選択します。
を選択してを作成します。
ユーザーフロー名を入力します (例: AsignioSignupSignin)。
[ ID プロバイダー] の [ ローカルアカウント] で、[なし] を選択 します。このアクションにより、電子メールとパスワードの認証が無効になります。
カスタム ID プロバイダーの場合は、作成された Asignio ID プロバイダーを選択します。
を選択してを作成します。

ユーザーフローをテストする

Azure AD B2C テナントで、[ ユーザーフロー] を選択します。
作成したユーザーフローを選択します。
[ アプリケーション] で、登録した Web アプリケーションを選択します。 応答 URL がhttps://jwt.ms。
ユーザーフローを実行する を選択します。
ブラウザーが Asignio サインインページにリダイレクトされます。
サインイン画面が表示されます。
下部にある [Asignio 認証] を選択します。

Asignio 署名がある場合は、認証のプロンプトを完了します。そうでない場合は、SMS OTP 経由で認証するデバイスの電話番号を指定します。リンクを使用して Asignio 署名を登録します。

ブラウザーが https://jwt.msにリダイレクトされます。 Azure AD B2C によって返されるトークンの内容が表示されます。

Asignio ポリシーキーを作成する

生成されたクライアントシークレットを Azure AD B2C テナントに格納します。
Azure portal にサインインします。
ポータルのツールバーで、[ ディレクトリとサブスクリプション] を選択します。
ポータルの設定 |ディレクトリとサブスクリプションのディレクトリ名の一覧で、Azure AD B2C ディレクトリを見つけます。
[切り替え] を選択します。
Azure portal の左上隅にある [ すべてのサービス] を選択します。
Azure AD B2C を検索して選択します。
[概要] ページで、[Identity Experience Framework] を選びます。
[ポリシーキー] を選択します。
[] を選択し、[] を追加します。
[オプション] で、[手動] を選択します。
ポリシーキーの名前を入力します。プレフィックス B2C_1A_ がキー名に追加されます。
[ シークレット] に、指定したクライアントシークレットを入力します。
[キー使用法] には [署名] を選択します。
を選択してを作成します。

ID プロバイダーとして Asignio を構成する

ヒント

開始する前に、Azure AD B2C ポリシーが構成されていることを確認します。そうでない場合は、カスタムポリシースターターパックの手順に従います。

ユーザーが Asignio でサインインするには、Azure AD B2C がエンドポイントを介して通信するクレームプロバイダーとして Asignio を定義します。エンドポイントは、デバイスでデジタル ID を使用してユーザー認証を検証するために Azure AD B2C が使用する要求を提供します。

クレームプロバイダーとして Asignio を追加する

GitHub からカスタムポリシースターターパックを取得し、LocalAccounts スターターパック内の XML ファイルを Azure AD B2C テナント名で更新します。

zip active-directory-b2c-custom-policy-starterpack をダウンロードするか、リポジトリを複製します。
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
LocalAccounts ディレクトリ内のファイルで、yourtenant文字列を Azure AD B2C テナント名に置き換えます。
LocalAccounts/ TrustFrameworkExtensions.xmlを開きます。
ClaimsProviders 要素を検索します。存在しない場合は、ルート要素の下に追加 TrustFrameworkPolicy。

次の例のような新しい ClaimsProvider を追加します。

 <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
         <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
         <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

client_id、指定した Asignio アプリケーション ID を使用して設定します。
client_secretセクションを、作成したポリシーキーで更新します。 B2C_1A_AsignioSecret の例を次に示します。
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
変更を保存します。

ユーザー体験を追加する

ID プロバイダーがサインインページにありません。

カスタムユーザージャーニーがある場合は、証明書利用者ポリシーの構成を続けてください。それ以外は、テンプレートユーザージャーニーをコピーしてください。
スターターパックから、 LocalAccounts/ TrustFrameworkBase.xmlを開きます。
を含む Id=SignUpOrSignIn 要素の内容を見つけてコピーします。
LocalAccounts/ TrustFrameworkExtensions.xmlを開きます。
UserJourneys 要素を見つけます。存在しない場合は、追加します。
UserJourney 要素の内容を UserJourneys 要素の子要素として貼り付けます。
ユーザージャーニー ID の名前を変更します。たとえば、Id=AsignioSUSI のようにします。

詳細情報: ユーザー体験

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

新しい ID プロバイダーをユーザー体験に追加します。

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

次の XML は、ID プロバイダーとのユーザー体験オーケストレーションを示しています。

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

依存先パーティーポリシーを構成する

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

依存先で、DefaultUserJourney 要素を見つけます。
追加した ID プロバイダーのユーザージャーニー ID と一致するように ReferenceId を更新します。

次の例では、 AsignioSUSI ユーザー体験の ReferenceId が AsignioSUSIに設定されています。

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

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

Azure portal にサインインします。
ポータルのツールバーで、[ ディレクトリとサブスクリプション] を選択します。
ポータルの設定 |ディレクトリとサブスクリプションのディレクトリ名の一覧で、Azure AD B2C ディレクトリを見つけます。
[切り替え] を選択します。
Azure portal で、 [Azure AD B2C] を検索して選択します。
[ポリシー] で、[ Identity Experience Framework] を選択します。
[ カスタムポリシーのアップロード] を選択します。
変更した 2 つのポリシーファイルを次の順序でアップロードします。

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

カスタムポリシーをテストする

Azure AD B2C テナントで、[ ポリシー] で [ Identity Experience Framework] を選択します。
[ カスタムポリシー] で、[ AsignioSUSI] を選択します。
[ アプリケーション] で、登録した Web アプリケーションを選択します。 応答 URL がhttps://jwt.ms。
[今すぐ実行] を選択します。
ブラウザーが Asignio サインインページにリダイレクトされます。
サインイン画面が表示されます。
下部にある [Asignio 認証] を選択します。

Asignio 署名がある場合は、Asignio Signature で認証するように求められます。そうでない場合は、SMS OTP 経由で認証するデバイスの電話番号を指定します。リンクを使用して Asignio 署名を登録します。

ブラウザーが https://jwt.msにリダイレクトされます。 Azure AD B2C によって返されるトークンの内容が表示されます。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-05-05