Azure Active Directory B2C に Trusona Authentication Cloud を構成する

[アーティクル]
01/26/2024

このサンプルチュートリアルでは、Azure AD B2C 認証と Trusona Authentication Cloud を統合する方法について説明します。これはクラウドベースのサービスであり、ユーザーは、モバイル認証アプリを必要とせずに、タップアンドゴー エクスペリエンスで認証を行うことができます。

Trusona Authentication Cloud と Azure AD B2C を統合する利点は次のとおりです。

より優れたユーザーエクスペリエンスで強力な認証を提供する
- オンラインの時間が増え、ユーザーの満足感が向上する
- 人員と放棄の削減、収益の増加
- 保持期間の増加、生涯価値 (LTV) の向上
ビジネスコストの削減
- アカウントの引き継ぎとアカウントの共有の削減
- 不正行為と手動による不正行為分析アクションの削減
- 手動レビューのアウトソーシング費用の削減
パスワードの撤廃
- パスワードのリセットが不要
- コールセンターへの苦情の削減
- パスキーを使用した高速かつ簡単で摩擦のないログイン

前提条件

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

Trusona Authentication Cloud 試用版アカウント。アカウントを要求するには、Trusona にお問い合わせください。
Azure サブスクリプション。サブスクリプションがない場合は、無料アカウントを取得できます。
お使いの Azure サブスクリプションにリンクされている Azure AD B2C テナント。

Azure AD B2C でのカスタムポリシーの概要に関する記事にある手順を完了してください。

シナリオの説明

Web 認証標準 - WebAuthn では、最新のオペレーティングシステムとブラウザーを実装して、指紋、Windows hello、または外部 FIDO デバイス (USB、Bluetooth、OTP など) による認証をサポートします。

このシナリオでは、Trusona は、パスワードレス認証を有効にする Azure AD B2C の ID プロバイダー (IdP) として機能します。このソリューションは、次のコンポーネントで構成されています。

サインインとサインアップを組み合わせた Azure AD B2C ポリシー。
IdP として Azure AD B2C に追加された Trusona Authentication Cloud。

Screenshot shows Trusona architecture diagram.

手順	説明
1.	ユーザーがブラウザーを使用して Web アプリケーションにサインインしようとします。
2.	Web アプリケーションが、Azure AD B2C のサインアップおよびサインインポリシーにリダイレクトされます。
3.	認証のために、Azure AD B2C によってユーザーが Trusona Authentication Cloud OpenID Connect (OIDC) IdP にリダイレクトされます。
4.	ユーザーに、ユーザー名 (通常はメールアドレス) を要求するサインイン Web ページが表示されます。
5.	ユーザーは、メールアドレスを入力し、[続行] ボタンを選択します。 Trusona Authentication Cloud でユーザーのアカウントが見つからない場合、デバイスで WebAuthn 登録プロセスを開始する応答がブラウザーに送信されます。それ以外の場合は、WebAuthn 認証プロセスを開始する応答がブラウザーに送信されます。
6.	ユーザーは、使用する資格情報を選択するように求められます。パスキーは、Web アプリケーションのドメインまたはハードウェアセキュリティキーに関連付けられています。ユーザーが資格情報を選択すると、OS は、生体認証、パスコード、または PIN を使用して ID を確認するようユーザーに要求します。これにより、セキュリティで保護されたエンクレーブまたは高信頼実行環境のロックが解除され、選択した資格情報に関連付けられた秘密キーによって署名された認証アサーションが生成されます。
7.	検証のために、認証アサーションが、Trusona クラウドサービスに返されます。
8.	検証が完了すると、Trusona Authentication Cloud (IdP) によって OIDC ID トークンが作成され、Azure AD B2C (サービスプロバイダー) に転送されます。 Azure AD B2C によって、Trusona の OpenID 検出ドキュメントの値に対してトークンと発行者の署名が検証されます。これらの詳細は、IdP のセットアップ時に構成されています。検証が完了すると、Azure AD B2C によって、(スコープに応じて) OIDC id_token が発行され、トークンを使用してユーザーが開始アプリケーションにリダイレクトされます。
9.	Web アプリケーション (または認証の実装に使用される開発者ライブラリ) は、トークンを取得し、Azure AD B2C トークンの信頼性を検証します。その場合は、要求を抽出し、それらを使用する Web アプリケーションに渡します。
10.	検証後、ユーザーはアクセスを許可または拒否されます。

手順 1: Trusona Authentication Cloud を使用してオンボードする

Trusona ポータルにサインインします。
左側のナビゲーションパネルで、[設定] を選択します
[設定] メニューで、[OIDC を有効にする]スライダーを選択します。
適切な[入力] を選択し、[リダイレクト URL]https://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp を指定します。
秘密鍵を [生成] し、そのキーを Azure AD B2C のセットアップで使用するために [コピー] します。
Note
1. Trusona ポータルでは、セルフサービス登録がサポートされています。登録すると、読み取り専用の権限を持つ Trusona アカウントが割り当てられます。その後、Trusona は正しいアカウントを割り当て、ポータルユーザーに対する組織のアクセス制御ポリシーに基づいて、権限を読み取り/書き込みに昇格させます。
2. Microsoft Entra ID の初期ドメイン名が、クライアントリダイレクトホストとして使用されます。

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

アプリケーションが Azure AD B2C と対話できるようにするには、アプリケーションを顧客のテナントに登録する必要があります。このチュートリアルでは、Azure portal を使用して Web アプリケーションを登録する方法を示します。このチュートリアルの場合のようなテスト目的では、トークンのデコードされたコンテンツを表示する Microsoft が所有する Web アプリケーションである https://jwt.ms を登録できます (トークンのコンテンツがお使いのブラウザー外に出ることはありません)。 Azure AD B2C テナントに Web アプリケーションを登録するには、新しい統合アプリ登録エクスペリエンスを使用します。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal で、 [Azure AD B2C] を検索して選択します。
[アプリの登録] を選択し、 [新規登録] を選択します。
アプリケーションの名前を入力します。たとえば、「jwt ms」と入力します。
[サポートされているアカウントの種類] で、 [Accounts in any identity provider or organizational directory (for authenticating users with user flows)]((ユーザーフローを使用してユーザーを認証するための) 任意の ID プロバイダーまたは組織のディレクトリのアカウント) を選択します。
[リダイレクト URI] で、 [Web] を選択し、URL テキストボックスに「https://jwt.ms」と入力します。

リダイレクト URI は、承認サーバー (この場合は Azure AD B2C) がユーザーを送信する先のエンドポイントです。ユーザーとの対話が完了した後、認証が成功すると、アクセストークンまたは認証コードが送信されます。実稼働アプリケーションでは、通常は https://contoso.com/auth-response などの、お使いのアプリが実行されているパブリックアクセスが可能なエンドポイントです。このチュートリアルの場合のようなテスト目的では、トークンのデコードされたコンテンツを表示する Microsoft が所有する Web アプリケーションである https://jwt.ms に設定できます (トークンのコンテンツがお使いのブラウザー外に出ることはありません)。アプリの開発時には、お使いのアプリケーションがローカルでリッスンする https://localhost:5000 などのエンドポイントを追加する場合があります。お使いの登録済みアプリケーションでは、いつでもリダイレクト URI を追加したり、変更したりすることができます。

リダイレクト URI には、次の制限があります。
- localhost リダイレクト URL を使用しない場合、応答 URL はスキーム https で始まる必要があります。
- 応答 URL では大文字と小文字が区別されます。大文字と小文字の区別は、実行中のアプリケーションの URL パスの場合と一致している必要があります。たとえば、ご利用のアプリケーションがそのパス .../abc/response-oidc の一部として含まれている場合は、応答 URL 内では .../ABC/response-oidc と指定しないでください。 Web ブラウザーでは大文字と小文字を区別を区別するものとしてパスが処理されるため、.../abc/response-oidc に関連付けられている cookie は、大文字と小文字が一致しない .../ABC/response-oidc URL にリダイレクトされた場合に除外される可能性があります。
- 応答 URL では、アプリケーションで想定されているように、末尾のスラッシュを含めるか除外する必要があります。たとえば、https://contoso.com/auth-response や https://contoso.com/auth-response/ は、アプリケーションで一致しない URL として扱われる場合があります。
[アクセス許可] で、 [openid と offline_access アクセス許可に対して管理者の同意を付与します] チェックボックスをオンにします。
[登録] を選択します。

ID トークンの暗黙的な許可の有効化

このアプリを登録し、ユーザーフローやカスタムポリシーをテストするために https://jwt.ms/ アプリでそれを構成する場合は、アプリの登録で暗黙の許可フローを有効にする必要があります。

左側のメニューの [管理] セクションで、 [認証] を選択します。
[暗黙的な許可およびハイブリッドフロー] で、[ID トークン (暗黙的およびハイブリッドフローに使用)] チェックボックスをオンにします。
[保存] を選択します。

手順 3: Azure AD B2C で Trusona Authentication Cloud を IdP として構成する

Azure AD B2C テナントの全体管理者として Azure Portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure Portal の左上隅の [すべてのサービス] を選択し、 [Azure AD B2C] を検索して選択します。
[ダッシュボード]>[Azure Active Directory B2C]>[ID プロバイダー] の順に移動します。
[Identity Providers] を選択します。
[追加] を選択します。

IdP を構成する

[ID プロバイダーの種類]>[OpenID Connect (Preview)] の順に選択します。

フォームに入力して、IdP を設定します。

プロパティ	値
メタデータ URL	`https://authcloud.trusona.net/.well-known/openid-configuration`
クライアント ID	Trusona Authentication Cloud ポータルで入手可能
クライアントシークレット	Trusona Authentication Cloud ポータルで入手可能
Scope	OpenID プロファイルの電子メール
応答の種類	code
応答モード	form_post

[OK] を選択します。
[Map this identity provider's claims] を選択します。
フォームに入力して、IdP をマップします。

プロパティ値

UserID sub

表示名 nickname

指定された名前 given_name

Surname family_name

応答モード email
[OK] を選択して、新しい OIDC IdP のセットアップを完了します。

プロパティ	値
UserID	sub
表示名	nickname
指定された名前	given_name
Surname	family_name
応答モード	email

手順 4: ユーザーフローポリシーを作成する

これで、Trusona が [新しい OpenID 接続 ID プロバイダー] として B2C IdP 内に表示されるようになります。

Azure AD B2C テナントの [ポリシー] で、 [ユーザーフロー] を選択します。
[新しいユーザーフロー] を選択します。
[サインアップとサインイン] を選択してバージョンを選択し、 [作成] を選択します。
ポリシーの [名前] を入力します。
[ID プロバイダー] セクションで、新しく作成した Trusona Authentication Cloud ID プロバイダーを選択します。

注意

Trusona は本質的に多要素であるため、多要素認証を無効にしておくことをお勧めします。
［作成］ を選択します
[ユーザー属性と要求] で [さらに表示する] を選択します。フォームで、前のセクションで ID プロバイダーのセットアップ時に指定した属性を、少なくとも 1 つ選択します。
[OK] を選択します。

手順 5: ユーザーフローをテストする

作成したポリシーを選択します。
[ユーザーフローを実行します] を選択し、設定を選択します。

a. アプリケーション: 登録済みアプリ (例: jwt ms) を選択します。

b. リダイレクト URL: リダイレクト URL (例: https://jwt.ms) を選択します。
[ユーザーフローを実行します] を選択します。 Trusona Authentication Cloud にリダイレクトされます。ユーザーに、ユーザー名 (通常はメールアドレス) を要求するサインイン Web ページが表示されます。 Trusona Authentication Cloud でユーザーのアカウントが見つからない場合、デバイスで WebAuthn 登録プロセスを開始する応答がブラウザーに送信されます。それ以外の場合は、WebAuthn 認証プロセスを開始する応答がブラウザーに送信されます。ユーザーは、使用する資格情報を選択するように求められます。パスキーは、Web アプリケーションのドメインまたはハードウェアセキュリティキーに関連付けられています。ユーザーが資格情報を選択すると、OS は、生体認証、パスコード、または PIN を使用して ID を確認するようユーザーに要求します。これにより、セキュリティで保護されたエンクレーブまたは高信頼実行環境のロックが解除され、選択した資格情報に関連付けられた秘密キーによって署名された認証アサーションが生成されます。 Azure AD B2C によって Trusona 認証応答が検証され、OIDC トークンが発行されます。これにより、ユーザーは開始アプリケーション (例: https://jwt.ms) にリダイレクトされ、Azure AD B2C から返されたトークンの内容が表示されます。

手順 3: Trusona Authentication Cloud ポリシーキーを作成する

先ほど手順 1. で生成したクライアントシークレットを Azure AD B2C テナントに保存します。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal の左上隅にある [すべてのサービス] を選択してから、 [Azure AD B2C] を検索して選択します。
[概要] ページで、 [Identity Experience Framework] を選択します。
[ポリシーキー] を選択し、 [追加] を選択します。
[オプション] では、 [手動] を選びます。
ポリシーキーの名前を入力します。たとえば、「 TrusonaTacClientSecret 」のように入力します。プレフィックス B2C_1A_ がキーの名前に自動的に追加されます。
[シークレット] に、前に記録したクライアントシークレットを入力します。
[キー使用法] として [Signature] を選択します。
［作成］ を選択します

手順 4: Trusona Authentication Cloud を IdP として構成する

ヒント

この時点で、Azure AD B2C ポリシーが構成されている必要があります。まだ済んでいない場合は、Azure AD B2C テナントを設定してポリシーを構成する方法についての手順を実行してください。

ユーザーが Trusona Authentication Cloud を使用してサインインできるようにするには、Trusona を、Azure AD B2C がエンドポイント経由で通信できるクレームプロバイダーとして定義する必要があります。エンドポイントには一連の要求が用意されています。Azure AD B2C では、これによってデバイスで使用可能なパスキーまたはハードウェアセキュリティキーを使用して特定のユーザーが認証済みであることを検証して、ユーザーの ID を証明します。

次の手順を使用して、Trusona をクレームプロバイダーとして追加します。

GitHub からカスタムポリシースターターパックを取得し、LocalAccounts スターターパック内の XML ファイルを実際の Azure AD B2C テナントの名前で更新します。
1. .zip ファイルをダウンロードするか、リポジトリを複製します。
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. LocalAccounts ディレクトリ内のすべてのファイルで、yourtenant 文字列を Azure AD B2C テナントの名前に置き換えます。たとえば、B2C テナントの名前が contosoであれば、yourtenant.onmicrosoft.com のすべてのインスタンスは contoso.onmicrosoft.com になります。
LocalAccounts/TrustFrameworkExtensions.xml を開きます。
ClaimsProviders 要素を見つけます。存在しない場合は、ルート要素 TrustFrameworkPolicy の下に追加します。
次に示すような新しい ClaimsProvider を追加します。

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
        <!-- trying to add additional claim-->
        <!--Insert b2c-extensions-app application ID here, for example: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="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 を、手順 1 で前もって記録した Trusona Authentication Cloud アプリケーション ID に設定します。
client_secret セクションを、手順 3. で作成したポリシーキーの名前で更新します。 B2C_1A_TrusonaTacClientSecret の例を次に示します。
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
変更を保存します。

手順 5: ユーザー体験を追加する

この時点で、ID プロバイダーは設定されていますが、まだどのサインインページでも使用することはできません。独自のカスタムユーザー体験がある場合は、手順 6. に進んでください。それ以外の場合は、次のように既存のテンプレートユーザー体験の複製を作成します。

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

手順 6 - IdP をユーザー体験に追加する

ユーザー体験ができたので、ユーザー体験に新しい ID プロバイダーを追加します。

ユーザー体験内で、Type=CombinedSignInAndSignUp または Type=ClaimsProviderSelection を含むオーケストレーションステップ要素を見つけます。これは通常、最初のオーケストレーションステップです。 ClaimsProviderSelections要素には、ユーザーがサインインできる IdPsのリストが含まれています。要素の順序により、ユーザーに表示されるサインインボタンの順序が制御されます。 ClaimsProviderSelection XML 要素を追加します。 TargetClaimsExchangeId の値をフレンドリ名 (例: TrusonaTacExchange) に設定します。
次のオーケストレーションステップで、ClaimsExchange 要素を追加します。 Id を、ターゲットの要求交換 ID の値に設定します。 TechnicalProfileReferenceId の値を、先ほどクレームプロバイダーを追加するときに作成した技術プロファイルの ID に更新します (TrusonaTAC-OpenIdConnect など)。

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

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

「ユーザー体験」で詳細をご覧いただけます。

手順 7: 証明書利用者ポリシーを構成する

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

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

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

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

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure portal で、 [Azure AD B2C] を検索して選択します。
[ポリシー] で [Identity Experience Framework] を選択します。
[カスタムポリシーのアップロード] を選択し、変更した 2 つのポリシーファイルを拡張ポリシー (TrustFrameworkExtensions.xml など)、証明書利用者ポリシー (SignUpOrSignin.xmlなど) の順序でアップロードします。

手順 9: カスタムポリシーをテストする

Azure AD B2C テナントで、[ポリシー] の下にある [Identity Experience Framework] を選択します。
[カスタムポリシー] で、[TrusonaTacSUSI] を選択します。
[アプリケーション] には、この記事の前提条件として以前に登録した Web アプリケーションを選択します。 (例: jwt ms)。 [応答 URL] に https://jwt.ms と表示されます。
[今すぐ実行] を選択します。ブラウザーが Trusona Authentication Cloud サインインページにリダイレクトされます。
サインイン画面が表示されます。一番下に、Trusona Authentication Cloud 認証を使用するためのボタンがあります。
Trusona Authentication Cloud にリダイレクトされます。ユーザーに、ユーザー名 (通常はメールアドレス) を要求するサインイン Web ページが表示されます。 Trusona Authentication Cloud でユーザーのアカウントが見つからない場合、デバイスで WebAuthn 登録プロセスを開始する応答がブラウザーに送信されます。それ以外の場合は、WebAuthn 認証プロセスを開始する応答がブラウザーに送信されます。ユーザーは、使用する資格情報を選択するように求められます。パスキーは、Web アプリケーションのドメインまたはハードウェアセキュリティキーに関連付けられています。ユーザーが資格情報を選択すると、OS は、生体認証、パスコード、または PIN を使用して ID を確認するようユーザーに要求します。これにより、セキュリティで保護されたエンクレーブまたは高信頼実行環境のロックが解除され、選択した資格情報に関連付けられた秘密キーによって署名された認証アサーションが生成されます。
サインインプロセスが成功すると、ブラウザーは https://jwt.ms にリダイレクトされ、Azure AD B2C によって返されたトークンの内容が表示されます。

次のステップ

追加情報については、次の記事を参照してください。

次の方法で共有

Azure Active Directory B2C に Trusona Authentication Cloud を構成する

前提条件

シナリオの説明

手順 1: Trusona Authentication Cloud を使用してオンボードする

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

ID トークンの暗黙的な許可の有効化

手順 3: Azure AD B2C で Trusona Authentication Cloud を IdP として構成する

IdP を構成する

手順 4: ユーザーフローポリシーを作成する

手順 5: ユーザーフローをテストする

手順 3: Trusona Authentication Cloud ポリシーキーを作成する

手順 4: Trusona Authentication Cloud を IdP として構成する

手順 5: ユーザー体験を追加する

手順 6 - IdP をユーザー体験に追加する

手順 7: 証明書利用者ポリシーを構成する

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

手順 9: カスタムポリシーをテストする

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Active Directory B2C に Trusona Authentication Cloud を構成する

前提条件

シナリオの説明

手順 1: Trusona Authentication Cloud を使用してオンボードする

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

ID トークンの暗黙的な許可の有効化

手順 3: Azure AD B2C で Trusona Authentication Cloud を IdP として構成する

IdP を構成する

手順 4: ユーザー フロー ポリシーを作成する

手順 5: ユーザー フローをテストする

手順 3: Trusona Authentication Cloud ポリシー キーを作成する

手順 4: Trusona Authentication Cloud を IdP として構成する

手順 5: ユーザー体験を追加する

手順 6 - IdP をユーザー体験に追加する

手順 7: 証明書利用者ポリシーを構成する

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

手順 9: カスタム ポリシーをテストする

次のステップ

フィードバック

その他のリソース

手順 4: ユーザーフローポリシーを作成する

手順 5: ユーザーフローをテストする

手順 3: Trusona Authentication Cloud ポリシーキーを作成する

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

手順 9: カスタムポリシーをテストする