共用方式為


使用 Azure Active Directory B2C 設定 Asignio 以進行多重要素驗證

瞭解如何將 azure AD B2C) 驗證與Asignio整合Microsoft Entra識別碼 (。 透過這項整合,為客戶提供無密碼、軟體生物特徵辨識和多重要素驗證體驗。 Asignio 使用專利的 Asignio 簽章和即時臉部驗證來進行使用者驗證。 可變更生物特徵辨識簽章有助於透過全通路驗證來減少密碼、詐騙、網路釣魚和認證重複使用。

開始之前

選擇原則類型選取器來指出原則類型設定。 Azure AD B2C 有兩種方法可定義使用者與應用程式互動的方式:

  • 預先定義的使用者流程
  • 可設定的自訂原則

本文中的步驟會因每個方法而有所不同。

深入了解:

必要條件

  • 連結至 Azure 訂用帳戶的 Azure AD B2C 租使用者

  • 請參閱教學 課程:建立 Azure Active Directory B2C 租使用者

  • Asignio 所簽發的 Asignio 用戶端識別碼和用戶端密碼。

  • 向 Asignio 註冊您的行動或 Web 應用程式即可取得這些權杖。

針對自訂原則

完成 教學課程:在 Azure AD B2C 中建立使用者流程和自訂原則

案例描述

此整合包括下列元件:

  • Azure AD B2C - 驗證使用者認證的授權伺服器
  • Web 或行動應用程式 - 使用 Asignio MFA 保護
  • Asignio Web 應用程式 - 使用者觸控裝置上的簽章生物特徵辨識收集

下圖說明實作。

顯示實作架構的圖表。

  1. 使用者在其行動或 Web 應用程式上開啟 Azure AD B2C 登入頁面,然後登入或註冊。
  2. Azure AD B2C 使用 OpenID Connect (OIDC) 要求,將使用者重新導向至 Asignio。
  3. 系統會將使用者重新導向至 Asignio Web 應用程式以進行生物特徵辨識登入。 如果使用者尚未註冊 Asignio Signature,他們可以使用 SMS One-Time-Password (OTP) 進行驗證。 驗證之後,使用者會收到註冊連結,以建立其 Asignio 簽章。
  4. 使用者會使用 Asignio 簽章和臉部驗證,或語音和臉部驗證進行驗證。
  5. 挑戰回應會移至 Asignio。
  6. Asignio 傳回 OIDC 對於 Azure AD B2C 登入的回應。
  7. Azure AD B2C 將驗證確認要求傳送給 Asignio,以確認收到驗證資料。
  8. 使用者被授與或拒絕應用程式存取權。

使用 Asignio 設定應用程式

使用 Asignio 設定應用程式與 Asignio 合作夥伴系統管理網站。

  1. 移至 asignio.com Asignio 合作夥伴系統管理 頁面,以要求貴組織的存取權。
  2. 使用認證登入 Asignio 合作夥伴系統管理。
  3. 使用您的 Azure AD B2C 租使用者建立 Azure AD B2C 應用程式的記錄。 當您搭配 Asignio 使用 Azure AD B2C 時,Azure AD B2C 會管理已連線的應用程式。 Asignio 應用程式代表Azure 入口網站中的應用程式。
  4. 在 Asignio 合作夥伴管理網站中,產生用戶端識別碼和用戶端密碼。
  5. 記下並儲存用戶端識別碼和用戶端密碼。 您稍後會用到它們。 Asignio 不會儲存用戶端密碼。
  6. 在網站中輸入使用者在驗證之後傳回的重新導向 URI。 使用下列 URI 模式。

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

  1. 上傳公司標誌。 當使用者登入時,它會出現在 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 中將 Asignio 設定為識別提供者

如需下列指示,請使用Microsoft Entra租使用者搭配 Azure 訂用帳戶。

  1. 以 Azure AD B2C 租使用者的全域管理員身分登入Azure 入口網站
  2. 在 [Azure 入口網站] 工具列中,選取[目錄 + 訂用帳戶]。
  3. 入口網站設定 |目錄 + 訂用帳戶,在[目錄名稱] 清單中,找出您的Microsoft Entra目錄。
  4. 選取 [切換]。
  5. 在Azure 入口網站左上角,選取[所有服務]。
  6. 搜尋並選取 [Azure AD B2C]。
  7. 在 Azure 入口網站中,搜尋並選取 [Azure AD B2C]。
  8. 在左側功能表中,選取 [識別提供者]。
  9. 選取 [新增 OpenID Connect 提供者]。
  10. 選取 [識別提供者類型]>[OpenID Connect]。
  11. 針對 [名稱],輸入 Asignio 登入或您選擇的名稱。
  12. 針對 [中繼資料 URL],輸入 https://authorization.asignio.com/.well-known/openid-configuration
  13. 針對 [用戶端識別碼],輸入您產生的 [用戶端識別碼]。
  14. 針對 [用戶端密碼],輸入您產生的用戶端密碼。
  15. 針對 [範圍],請使用 openid 電子郵件設定檔
  16. 針對 [回應類型],請使用 程式碼
  17. 針對 [回應模式],請使用 查詢
  18. 針對 [網域提示],請使用 https://asignio.com
  19. 選取 [確定]。
  20. 選取 [對應此身分識別提供者的宣告]。
  21. 針對 [使用者識別碼],請使用 sub
  22. 針對 [顯示名稱],請使用 name
  23. 針對 [指定名稱],請使用 given_name
  24. 針對 Surname,請使用 family_name
  25. 針對 Email,請使用 電子郵件
  26. 選取 [儲存]。

建立使用者流程原則

  1. 在您的 Azure AD B2C 租用戶中,選取 [原則] 下的 [使用者流程]。
  2. 選取 [新增使用者流程]。
  3. 選取 [註冊並登入 使用者流程類型]。
  4. 選取 [建議的版本]。
  5. 選取 [建立]。
  6. 輸入使用者流程 名稱,例如 AsignioSignupSignin
  7. [識別提供者] 底下,針對 [ 本機帳戶],選取 [無]。 此動作會停用電子郵件和密碼驗證。
  8. 針對 [自訂識別提供者],選取已建立的 Asignio Identity 提供者。
  9. 選取 [建立]。

測試您的使用者流程

  1. 在 Azure AD B2C 租用戶中,選取 [使用者流程]
  2. 選取已建立的使用者流程。
  3. 針對 [應用程式],選取您註冊的 Web 應用程式。 回復 URLhttps://jwt.ms
  4. 選取 [執行使用者流程]。
  5. 瀏覽器會重新導向至 Asignio 登入頁面。
  6. [登入] 畫面隨即出現。
  7. 在底部,選取 [Asignio 驗證]。

如果您有 Asignio 簽章,請完成驗證的提示。 如果沒有,請提供裝置電話號碼,以透過 SMS OTP 進行驗證。 使用連結來註冊您的 Asignio 簽章。

  1. 瀏覽器會重新導向至 https://jwt.ms 。 Azure AD B2C 傳回的權杖內容隨即出現。

建立 Asignio 原則金鑰

  1. 將產生的用戶端密碼儲存在 Azure AD B2C 租使用者中。
  2. 登入 Azure 入口網站
  3. 在入口網站工具列中,選取 [目錄 + 訂用帳戶]。
  4. 入口 網站設定 |目錄 + 訂用帳戶,在 [目錄名稱 ] 清單中,找出您的 Azure AD B2C 目錄。
  5. 選取 [切換]。
  6. 在Azure 入口網站左上角,選取[所有服務]。
  7. 搜尋並選取 [Azure AD B2C]。
  8. 在 [概觀] 頁面上,選取 [識別體驗架構]。
  9. 選取 [ 原則金鑰]。
  10. 選取 [新增]。
  11. 針對 [選項],選取 [手動]。
  12. 輸入原則金鑰 的原則金鑰 [名稱 ] 作為原則金鑰。 前置詞 B2C_1A_ 會附加至金鑰名稱。
  13. [秘密] 中,輸入您注意到的 [用戶端密碼]。
  14. 針對 [金鑰使用方法] 選取 [簽章]。
  15. 選取 [建立]。

將 Asignio 設定為識別提供者

提示

開始之前,請確定已設定 Azure AD B2C 原則。 如果沒有,請遵循 自訂原則入門套件中的指示。

若要讓使用者使用 Asignio 登入,請將 Asignio 定義為 Azure AD B2C 透過端點與通訊的宣告提供者。 端點會提供 Azure AD B2C 用來在裝置上使用數位識別碼來驗證使用者驗證的宣告。

將 Asignio 新增為宣告提供者

從 GitHub 取得自訂原則入門套件,然後使用 Azure AD B2C 租用戶名稱更新 LocalAccounts 入門套件中的 XML 檔案:

  1. 下載 zip active-directory-b2c-custom-policy-starterpack 或複製存放庫:

        git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
    
  2. LocalAccounts 目錄中的檔案中,將字串 yourtenant 取代為 Azure AD B2C 租使用者名稱。

  3. 開啟 LocalAccounts/ TrustFrameworkExtensions.xml

  4. 尋找 ClaimsProviders 元素。 如果沒有,請在根項目底下新增它。 TrustFrameworkPolicy

  5. 新增類似下列範例的新 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">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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>
    
  6. 使用您指定的 Asignio 應用程式識別碼 來設定client_id

  7. 使用您所建立的原則金鑰更新 client_secret 區段。 例如,B2C_1A_AsignioSecret

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
    
  8. 儲存變更。

新增使用者旅程圖

識別提供者不在登入頁面中。

  1. 如果您有自訂使用者旅程圖繼續設定 信賴憑證者原則,否則請複製範本使用者旅程圖:
  2. 從入門套件中,開啟 LocalAccounts/ TrustFrameworkBase.xml
  3. 找出並複製包含 Id=SignUpOrSignInUserJourney元素內容。
  4. 開啟 LocalAccounts/ TrustFrameworkExtensions.xml
  5. 找出 UserJourneys 元素。 如果沒有,請新增一個。
  6. 將 UserJourney 元素內容貼上為 UserJourneys 元素的子系。]
  7. 重新命名使用者旅程 圖識別碼。 例如: Id=AsignioSUSI

深入瞭解: 使用者旅程圖

將識別提供者新增至使用者旅程圖

將新的識別提供者新增至使用者旅程圖。

  1. 在使用者旅程圖中,尋找包含 Type=CombinedSignInAndSignUpType=ClaimsProviderSelection 的協調流程步驟元素。 這通常是第一個協調流程步驟。 ClaimsProviderSelections元素具有使用者用來登入的識別提供者清單。 元素的順序會控制登入按鈕的順序。
  2. 新增 ClaimsProviderSelection XML 元素。
  3. TargetClaimsExchangeId 的值設定為易記名稱。
  4. 新增 ClaimsExchange 元素。
  5. 識別碼設定為目標宣告交換識別碼的值。
  6. TechnicalProfileReferenceId 的值更新為您建立的技術設定檔識別碼。

下列 XML 示範與識別提供者的使用者旅程協調流程。

    <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 執行的使用者旅程圖。

  1. 在信賴憑證者中,找出 DefaultUserJourney 元素。
  2. 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>

上傳自訂原則

  1. 登入 Azure 入口網站
  2. 在入口網站工具列中,選取 [目錄 + 訂用帳戶]。
  3. 入口 網站設定 |目錄 + 訂用帳戶,在 [目錄名稱 ] 清單中,找出您的 Azure AD B2C 目錄。
  4. 選取 [切換]。
  5. 在 Azure 入口網站中,搜尋並選取 [Azure AD B2C]。
  6. 在 [原則] 下,選取 [Identity Experience Framework]。
  7. 選取 [上傳自訂原則]。
  8. 依下列順序上傳您變更的兩個原則檔案:
  • 擴充原則,例如 TrustFrameworkExtensions.xml
  • 信賴憑證者原則,例如 SignUpOrSignin.xml

測試自訂原則

  1. 在 Azure AD B2C 租用戶的 [原則] 下,選取 [Identity Experience Framework]。
  2. 在 [自訂原則] 底下,選取 [AsignioSUSI]。
  3. 針對 [應用程式],選取您註冊的 Web 應用程式。 回復 URLhttps://jwt.ms
  4. 選取 [立即執行]。
  5. 瀏覽器會重新導向至 Asignio 登入頁面。
  6. [登入] 畫面隨即出現。
  7. 在底部,選取 [Asignio 驗證]。

如果您有 Asignio 簽章,系統會提示您向 Asignio 簽章進行驗證。 如果沒有,請提供裝置電話號碼,以透過 SMS OTP 進行驗證。 使用連結來註冊您的 Asignio 簽章。

  1. 瀏覽器會重新導向至 https://jwt.ms 。 Azure AD B2C 傳回的權杖內容隨即出現。

下一步