共用方式為


使用 Azure Active Directory B2C 設定 Trusona Authentication Cloud

在本範例教學課程中,您將瞭解如何整合 Azure AD B2C 驗證與 Trusona Authentication Cloud。 這是一項雲端式服務,可讓使用者使用 點選和移至 體驗進行驗證,而不需要任何類型的行動驗證器應用程式。

將 Trusona Authentication Cloud 與 Azure AD B2C 整合的優點包括:

  • 以更佳的用戶體驗提供強式驗證

    • 更快樂的用戶,他們花更多的在線
    • 降低流失和放棄,增加收入
    • 較高的保留期、存留期值 (LTV)
  • 降低企業執行成本

    • 減少帳戶接管和帳戶共用
    • 減少詐騙和較少的手動詐騙分析動作
    • 減少外包手動檢閱的支出
  • 消除密碼

    • 不再重設密碼
    • 減少客服中心投訴
    • 使用複雜金鑰快速、簡單、無摩擦的登入

必要條件

若要開始,您需要:

案例描述

Web 驗證標準 - WebAuthn 會實作新式操作系統和瀏覽器,以支援透過手指列印、Windows hello 或外部 FIDO 裝置進行驗證,例如 USB、藍牙 和 OTP。

在此案例中,Trusona 會作為 Azure AD B2C 的識別提供者(IdP)來啟用無密碼驗證。 下列元件組成解決方案:

  • Azure AD B2C 合併登入和註冊原則。
  • Trusona Authentication Cloud 已新增至 Azure AD B2C 作為 IdP。

Screenshot shows Trusona architecture diagram.

步驟 描述
1. 用戶嘗試透過瀏覽器登入 Web 應用程式。
2. Web 應用程式會重新導向至 Azure AD B2C 註冊和登入原則。
3. Azure AD B2C 會將使用者重新導向驗證至 Trusona Authentication Cloud OpenID 連線 (OIDC) IdP。
4. 使用者會看到登入網頁,要求其使用者名稱 – 通常是電子郵件位址。
5. 使用者輸入其電子郵件地址,然後選取 [ 繼續] 按鈕。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶,則會將回應傳送至瀏覽器,以在裝置上起始 WebAuthn 註冊程式。 否則,回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。
6. 系統會要求用戶選取要使用的認證。 複雜金鑰會與 Web 應用程式的網域或硬體安全性金鑰相關聯。 用戶選取認證之後,OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這會解除鎖定 Secure Enclave/Trusted Execution 環境,其會產生由與所選認證相關聯的私鑰所簽署的驗證判斷提示。
7. 驗證判斷提示會傳回 Trusona 雲端服務以進行驗證。
8. 驗證之後,Trusona Authentication Cloud (IdP) 會建立 OIDC 標識符令牌,然後將它轉送至 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 上線

  1. 登入 Trusona 入口網站

  2. 從左側導覽面板中,選取 [設定

  3. 在 [設定] 功能表中,選取滑桿以啟用 OIDC

  4. 選取適當的輸入,並提供重新導向URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp

  5. 產生 秘密金鑰,並 複製 金鑰以用於您的 Azure AD B2C 設定。

    注意

    1. Trusona 入口網站支援自助式註冊。 註冊之後,系統會將您指派給具有只讀許可權的 Trusona 帳戶。 之後,Trusona 會將您指派給正確的帳戶,並根據組織的入口網站使用者的訪問控制原則,將許可權提升為讀寫許可權。
    2. Microsoft Entra ID 的初始功能變數名稱會作為用戶端重新導向主機。

    Screenshot shows Trusona Authentication Cloud portal settings.

步驟 2:在 Azure AD B2C 中註冊 Web 應用程式

您的應用程式必須先在客戶租用戶中註冊,應用程式才能與 Azure AD B2C 互動。 本教學課程說明如何使用 Azure 入口網站 註冊 Web 應用程式。 基於本教學課程等測試目的,您要註冊 https://jwt.ms,這是一個 Microsoft 擁有的 Web 應用程式,其會顯示令牌的已譯碼內容(令牌的內容永遠不會離開瀏覽器)。 若要在您的 Azure AD B2C 租用戶中註冊 Web 應用程式,請使用我們新的整合應用程式註冊體驗。

  1. 登入 Azure 入口網站

  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 [設定] 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。

  3. 在 Azure 入口網站中,搜尋並選取 [Azure AD B2C]

  4. 選取 [應用程式註冊],然後選取 [新增註冊]

  5. 輸入 應用程式的 [名稱 ]。 例如, jwt ms

  6. 在 [支援的帳戶類型] 下,選取 [任何身分識別提供者或組織目錄中的帳戶 (用於運用使用者流程來驗證使用者)]

  7. 在 [重新導向 URI] 底下,選取 [Web],然後在 [URL] 文本框中輸入 https://jwt.ms

    重新導向 URI 是授權伺服器所在的端點,在此情況下,Azure AD B2C 會將用戶傳送至該端點。 完成與用戶的互動之後,會在成功授權時傳送存取令牌或授權碼。 在生產應用程式中,它通常是應用程式執行所在的可公開存取端點,例如 https://contoso.com/auth-response。 基於本教學課程之類的測試目的,您可以將它設定為 https://jwt.ms,這是一個 Microsoft 擁有的 Web 應用程式,其會顯示令牌的已譯碼內容(令牌的內容永遠不會離開瀏覽器)。 在應用程式開發期間,您可以新增應用程式在本機接聽的端點,例如 https://localhost:5000。 您可以隨時在已註冊的應用程式中新增和修改重新導向 URI。

    下列限制適用於重新導向 URI:

    • 除非您使用localhost重新導向URL,否則回復URL必須以配置 https開頭。
    • 回復 URL 會區分大小寫。 其大小寫必須符合執行中應用程式的 URL 路徑大小寫。 例如,如果您的應用程式在其路徑 .../abc/response-oidc中包含 ,請勿在回覆 URL 中指定 .../ABC/response-oidc 。 由於網頁瀏覽器會將路徑視為區分大小寫,因此如果重新導向至不相符.../ABC/response-oidc的 URL,則可能會排除與相關聯的 .../abc/response-oidc Cookie。
    • 回復 URL 應包含或排除尾端正斜線,因為您的應用程式預期。 例如, https://contoso.com/auth-responsehttps://contoso.com/auth-response/ 可能會被視為應用程式中的非相符URL。
  8. 在 [許可權]下,選取 [授與系統管理員同意以開啟標識符和offline_access許可權] 複選框。

  9. 選取註冊

啟用標識元令牌隱含授與

如果您註冊此應用程式並使用 https://jwt.ms/ 應用程式來測試使用者流程或自定義原則,則必須在應用程式註冊中啟用隱含授與流程:

  1. 在左側功能表中,於 [管理]下,選取 [驗證]

  2. 在 [隱含授與和混合式流程] 底下,選取 [用於隱含和混合式流程] 複選框。

  3. 選取 [儲存]。

步驟 3:在 Azure AD B2C 中將 Trusona Authentication Cloud 設定為 IdP

  1. 以 Azure AD B2C 租使用者的全域管理員身分登入 Azure 入口網站

  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 設定 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。

  3. 選擇 Azure 入口網站 左上角的 [所有服務],搜尋並選取 [Azure AD B2C]。

  4. 流覽至儀錶板>Azure Active Directory B2C>識別提供者。

  5. 選取 [ 識別提供者]。

  6. 選取新增

設定IdP

  1. 選取 [識別提供者類型>] 連線 [預覽]。

  2. 填寫表單以設定 IdP:

    屬性
    元數據 URL https://authcloud.trusona.net/.well-known/openid-configuration
    用戶端識別碼 可在 Trusona Authentication Cloud 入口網站上取得
    用戶端密碼 可在 Trusona Authentication Cloud 入口網站上取得
    範圍 OpenID 設定檔電子郵件
    回應類型 code
    回應模式 form_post
  3. 選取 [確定]。

  4. 選取 [ 對應此識別提供者的宣告]。

  5. 填寫表單以對應 IdP:

    屬性
    UserID sub
    顯示名稱 昵稱
    指定的名稱 given_name
    Surname family_name
    回應模式 電子郵件
  6. 選取 [ 確定 ] 以完成新 OIDC IdP 的設定。

步驟 4:建立使用者流程原則

您現在應該會看到 Trusona 作為新的 OpenID 連線 識別提供者,列在 B2C IdP 內。

  1. 在您的 Azure AD B2C 租使用者中,於 [原則] 底下,選取 [使用者流程]。

  2. 選取 [新增使用者流程]。

  3. 選取 [註冊並登入],選取版本,然後選取 [ 建立]。

  4. 輸入原則的 [ 名稱 ]。

  5. 在 [ 識別提供者 ] 區段中,選取您新建立 的 Trusona Authentication Cloud-Identity Provider

    注意

    由於 Trusona 本質上是多重要素,因此最好停用多重要素驗證。

  6. 選取建立

  7. 在 [用戶屬性和宣告],選擇 [顯示更多]。 在表單中,選取您在上一節中設定識別提供者期間指定的至少一個屬性。

  8. 選取 [確定]。

步驟 5:測試您的使用者流程

  1. 選取您建立的原則。

  2. 選取 [ 執行使用者流程],然後選取設定:

    a. 應用程式:選取已註冊的應用程式,例如 jwt ms。

    b. 回覆 URL:選取重新導向 URL, 例如 https://jwt.ms

  3. 選取執行使用者流程。 您應該重新導向至 Trusona Authentication Cloud。 使用者會看到登入網頁,要求其使用者名稱 – 通常是電子郵件位址。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶,則會將回應傳送至瀏覽器,以在裝置上起始 WebAuthn 註冊程式。 否則,回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。 系統會要求用戶選取要使用的認證。 複雜金鑰會與 Web 應用程式的網域或硬體安全性金鑰相關聯。 用戶選取認證之後,OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這會解除鎖定 Secure Enclave/Trusted Execution 環境,其會產生由與所選認證相關聯的私鑰所簽署的驗證判斷提示。 Azure AD B2C 會驗證 Trusona 驗證回應,併發出 OIDC 令牌。 它會將使用者重新導向回起始的應用程式,例如 , https://jwt.ms其會顯示 Azure AD B2C 所傳回之令牌的內容。

步驟 3:建立 Trusona Authentication Cloud 原則密鑰

儲存您先前在 Azure AD B2C 租使用者的步驟 1產生的客戶端密碼。

  1. 登入 Azure 入口網站

  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 設定 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。

  3. 選擇 Azure 入口網站 左上角的 [所有服務],然後搜尋並選取 [Azure AD B2C]。

  4. 在 [概觀] 頁面上,選取 [ 身分識別體驗架構]。

  5. 選取 [ 原則密鑰 ],然後選取 [ 新增]。

  6. 針對 [ 選項],選擇 [ 手動]。

  7. 輸入 原則金鑰的 [名稱 ]。 例如: TrusonaTacClientSecret 。 前置詞 B2C_1A_ 會自動新增至金鑰的名稱。

  8. 在 [秘密] 中,輸入您先前記錄的客戶端密碼。

  9. 針對 [ 金鑰使用方式],選取 Signature

  10. 選取建立

步驟 4:將 Trusona Authentication Cloud 設定為 IdP

提示

此時您應該已設定 Azure AD B2C 原則。 如果沒有,請 遵循如何設定 Azure AD B2C 租用戶和設定原則的指示

若要讓使用者使用 Trusona Authentication Cloud 登入,您必須將 Trusona 定義為 Azure AD B2C 可以透過端點進行通訊的宣告提供者。 端點提供一組宣告,供 Azure AD B2C 用來驗證特定使用者已使用其裝置上可用的複雜密鑰或硬體安全性金鑰進行驗證,證明使用者的身分識別。

使用下列步驟將 Trusona 新增為宣告提供者:

  1. 從 GitHub 取得自定義原則入門套件,然後使用您的 Azure AD B2C 租使用者名稱更新 LocalAccounts 入門套件中的 XML 檔案:

    1. 下載 .zip 檔案 或複製存放庫:

          git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
      
    2. 在 LocalAccounts 目錄中的所有檔案中,以 Azure AD B2C 租使用者的名稱取代字串yourtenant。 例如,如果 B2C 租使用者的名稱是 contoso,則的所有實體都會 yourtenant.onmicrosoft.com 變成 contoso.onmicrosoft.com

  2. 開啟 LocalAccounts/TrustFrameworkExtensions.xml

  3. 尋找 ClaimsProviders 元素。 如果不存在,請將它新增至根元素底下。 TrustFrameworkPolicy

  4. 新增類似如下所示的新 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>
  1. 使用您先前在步驟 1記錄的 Trusona Authentication Cloud 應用程式標識碼來設定client_id

  2. 使用步驟 3建立的原則金鑰名稱更新client_secret區段。 例如: B2C_1A_TrusonaTacClientSecret

    <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
    
  3. 儲存變更。

步驟 5:新增使用者旅程圖

此時,您已設定 IdP,但尚未在任何登入頁面中提供。 如果您擁有自己的自定義使用者旅程圖繼續執行 步驟 6,則請建立現有範本使用者旅程圖的複本,如下所示:

  1. LocalAccounts/TrustFrameworkBase.xml從入門套件開啟檔案。

  2. 尋找並複製包含 Id=SignUpOrSignIn之 UserJourney 元素的整個內容

  3. 開啟 並 LocalAccounts/TrustFrameworkExtensions.xml 尋找 UserJourneys 元素。 如果專案不存在,請新增一個。

  4. 貼上您複製為 UserJourneys 元素子系之 UserJourney 元素的整個內容。

  5. Id重新命名使用者旅程圖的 。 例如: Id=TrusonaTacSUSI

步驟 6:將 IdP 新增至使用者旅程圖

現在您已擁有使用者旅程圖,請將新的 IdP 新增至使用者旅程圖。

  1. 尋找在 Type=CombinedSignInAndSignUp使用者旅程圖中包含 或 Type=ClaimsProviderSelection 的協調流程步驟元素。 通常是第一個協調流程步驟。 ClaimsProviderSelections 元素包含使用者可以登入的 IdP 清單。 元素的順序會控制向用戶呈現的登入按鈕順序。 新增 ClaimsProviderSelection XML 元素。 將 TargetClaimsExchangeId 的值設定為易記名稱,例如 TrusonaTacExchange

  2. 在下一個 協調流程步驟中,新增 ClaimsExchange 元素。 將標識碼設定為目標宣告交換標識碼的值。 將 TechnicalProfileReferenceId 的值更新為您稍早建立之技術設定檔的識別碼,例如 , TrusonaTAC-OpenIdConnect

下列 XML 示範身分識別提供者使用者旅程圖的協調流程步驟:

    <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元素。 更新 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:上傳自定義原則

  1. 登入 Azure 入口網站

  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 設定 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。

  3. Azure 入口網站 中,搜尋並選取 [Azure AD B2C]。

  4. 在 [原則] 底下,選取 [ 身分識別體驗架構]。

  5. 選取 [ 上傳自定義原則],然後上傳您變更的兩個原則檔案,順序如下:擴充原則,例如 TrustFrameworkExtensions.xml,然後是信賴憑證者原則,例如 SignUpOrSignin.xml

步驟 9:測試您的自定義原則

  1. 在您的 Azure AD B2C 租使用者中,選取 [原則] 底下的 [身分識別體驗架構]。

  2. 在 [自定義原則] 底下,選取 [TrusonaTacSUSI]。

  3. 針對 [ 應用程式],選取您先前註冊為本文必要條件一部分的 Web 應用程式。 例如 jwt ms。 回覆 URL 應該會顯示 https://jwt.ms

  4. 選取 [ 立即執行]。 您的瀏覽器應該重新導向至 Trusona Authentication Cloud 登入頁面。

  5. 顯示登入畫面;底部應該是使用 Trusona 驗證雲端 驗證的按鈕。

  6. 您應該重新導向至 Trusona Authentication Cloud。 使用者會看到登入網頁,要求其使用者名稱 – 通常是電子郵件位址。 如果在 Trusona Authentication Cloud 中找不到使用者帳戶,則會將回應傳送至瀏覽器,以在裝置上起始 WebAuthn 註冊程式。 否則,回應會傳送至開始 WebAuthn 驗證程式的瀏覽器。 系統會要求用戶選取要使用的認證。 複雜金鑰會與 Web 應用程式的網域或硬體安全性金鑰相關聯。 用戶選取認證之後,OS 會要求使用者使用生物特徵辨識、密碼或 PIN 來確認其身分識別。 這會解除鎖定 Secure Enclave/Trusted Execution 環境,其會產生由與所選認證相關聯的私鑰所簽署的驗證判斷提示。

  7. 如果登入程式成功,您的瀏覽器會重新導向至 https://jwt.ms,以顯示 Azure AD B2C 所傳回令牌的內容。

下一步

如需詳細資訊,請檢閱下列文章: