你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用 Azure Active Directory B2C 配置 Asignio 以进行多重身份验证

重要

自 2025 年 5 月 1 日起,Azure AD B2C 将不再可供新客户购买。 在我们的常见问题解答中了解详细信息

了解如何将 Microsoft Entra ID (Azure AD B2C) 身份验证与 Asignio 集成。 通过此集成,为客户提供无密码、软生物识别和多因素身份验证体验。 Asignio 使用获得专利的 Asignio Signature 和实时面部验证进行用户身份验证。 可更改的生物识别签名有助于通过全渠道身份验证减少密码、欺诈、网络钓鱼和凭据重用。

在您开始之前

选择策略类型选择器以指示策略类型设置。 Azure AD B2C 有两种方法来定义用户如何与应用程序交互:

  • 预定义的用户流
  • 可配置的自定义策略

本文中的步骤因每种方法而异。

了解详细信息:

先决条件

  • 一个链接到 Azure 订阅的 Azure AD B2C 租户

  • 请参阅 教程:创建 Azure Active Directory B2C 租户

  • 由 Asignio 颁发的 Asignio 客户端 ID 和客户端密钥。

  • 这些令牌是通过向 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 签名,他们可以使用 SMS One-Time-Password (OTP) 进行身份验证。 身份验证后,用户会收到一个注册链接,用于创建其 Asignio 签名。
  4. 用户使用 Asignio Signature 和面部验证或语音和面部验证进行身份验证。
  5. 质询响应发送到 Asignio。
  6. Asignio 返回对 Azure AD B2C 登录的 OIDC 响应。
  7. Azure AD B2C 向 Asignio 发送身份验证验证请求,以确认收到身份验证数据。
  8. 授予或拒绝用户对应用程序的访问权限。

使用 Asignio 配置应用程序

使用 Asignio 配置应用程序是通过 Asignio 合作伙伴管理站点进行的。

  1. 要为您的组织请求访问权限,请转到 Asignio 合作伙伴管理 页面 asignio.com。
  2. 使用凭据登录到 Asignio Partner Administration。
  3. 使用您的 Azure AD B2C 租户为 Azure AD B2C 应用程序创建一个记录。 将 Azure AD B2C 与 Asignio 配合使用时,Azure AD B2C 会管理连接的应用程序。 Asignio 应用表示 Azure 门户中的应用。
  4. 在 Asignio 合作伙伴管理站点中,生成客户端 ID 和客户端密钥。
  5. 记下并存储 Client ID 和 Client Secret。 稍后会使用到它们。 Asignio 不存储客户端密钥。
  6. 在网站中输入重定向 URI,该 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 租户的 B2C IEF 策略管理员身份登录到 Azure 门户
  2. 在 Azure 门户工具栏中,选择 “目录 + 订阅”。
  3. Portal 设置 |目录 + 订阅,在 目录名称 列表中,找到您的 Microsoft Entra 目录。
  4. 选择“ 切换”。
  5. 在 Azure 门户的左上角,选择 “所有服务”。
  6. 搜索并选择“Azure AD B2C”
  7. 在 Azure 门户中,搜索并选择 Azure AD B2C
  8. 在左侧菜单中,选择 Identity providers(身份提供商)。
  9. 选择“新的 OpenID Connect 提供程序”
  10. 选择 标识提供者类型>OpenID Connect
  11. 请输入 Asignio 登录名称或您选择的名称作为 名称
  12. 对于 元数据 URL,请输入 https://authorization.asignio.com/.well-known/openid-configuration
  13. 对于 Client ID (客户端 ID),输入您生成的 Client ID (客户端 ID)。
  14. 对于 Client Secret (客户端密钥),输入您生成的 Client Secret (客户端密钥)。
  15. “范围”使用“OpenID 电子邮件配置文件”
  16. 对于 Response type (响应类型),请使用 code.
  17. 对于 Response mode (响应模式),请使用 query
  18. “域提示”使用 https://asignio.com
  19. 选择“确定”
  20. 选择“映射此标识提供者的声明”
  21. 对于 用户 ID,请使用
  22. 对于 Display Name,请使用 name
  23. 对于 Given Name,请使用 given_name
  24. 对于 姓氏,请使用 family_name
  25. 对于 Email,请使用 email
  26. 选择“保存”

创建用户流策略

  1. 在 Azure AD B2C 租户的 “策略”下,选择 “用户流”。
  2. 选择“新建用户流”。
  3. 选择 “注册并登录 用户流类型”。
  4. 选择 Version Recommended(建议的版本)。
  5. 选择 创建
  6. 输入用户流 名称,例如 AsignioSignupSignin.
  7. 身份提供商下,对于 本地账户,选择 。 此操作将禁用电子邮件和密码身份验证。
  8. 在“自定义标识提供者”中,选择创建的 Asignio 标识提供者
  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. Portal 设置 |目录 + 订阅,在 “目录名称 ”列表中,找到 Azure AD B2C 目录。
  5. 选择“ 切换”。
  6. 在 Azure 门户的左上角,选择 “所有服务”。
  7. 搜索并选择“Azure AD B2C”
  8. 在“概述”页上选择“标识体验框架”。
  9. 选择 策略密钥
  10. 选择 并添加
  11. 对于 “选项”,请选择“ 手动”。
  12. 输入策略密钥名称 名称 。 前缀 B2C_1A_ 将追加到密钥名称中。
  13. Secret (密钥) 中,输入您记下的 Client Secret (客户端密钥)。
  14. 对于“密钥用法”,请选择“签名”
  15. 选择 创建

将 Asignio 配置为身份提供程序

小窍门

在开始之前,请确保已配置 Azure AD B2C 策略。 如果没有,请按照 自定义策略初学者包中的说明进行操作。

为了让用户使用 Asignio 登录,请将 Asignio 定义为 Azure AD B2C 可通过终结点与其进行通信的声明提供程序。 终结点提供 Azure AD B2C 用于在其设备上使用数字 ID 验证用户身份验证的声明。

将 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">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>
    
  6. 使用您记下的 Asignio 应用程序 ID 设置 client_id

  7. 使用您创建的策略密钥更新 client_secret 部分。 例如,B2C_1A_AsignioSecret

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
    
  8. 保存更改。

添加用户旅程

身份提供商不在登录页面中。

  1. 如果您有自定义用户旅程,请继续 配置信赖方策略,否则,请复制模板用户旅程:
  2. 在初学者包中,打开 LocalAccounts/TrustFrameworkBase.xml
  3. 找到并复制 UserJourney 元素的内容,其中包括 Id=SignUpOrSignIn
  4. 打开 LocalAccounts/TrustFrameworkExtensions.xml
  5. 找到 UserJourneys 元素。 如果没有,请添加一个。
  6. 将 UserJourney 元素内容粘贴为 UserJourneys 元素的子项。]
  7. 重命名用户历程 ID。 例如,Id=AsignioSUSI

了解更多: 用户旅程

将标识提供者添加到用户旅程

将新的标识提供者添加到用户旅程。

  1. 在用户旅程中,查找包含 Type=CombinedSignInAndSignUpType=ClaimsProviderSelection 的业务流程步骤元素。 通常这是第一个编排步骤。 ClaimsProviderSelections 元素具有用户登录时使用的标识提供者列表。 元素的顺序控制登录按钮的顺序。
  2. 添加ClaimsProviderSelection XML 元素。
  3. 将 TargetClaimsExchangeId 的值设置为易记名称。
  4. 添加 ClaimsExchange 元素。
  5. ID 设置为目标声明交换 ID 的值。
  6. TechnicalProfileReferenceId 的值更新为所创建的技术配置文件的 ID。

以下 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,使其与已在其中添加标识提供者的用户旅程 ID 匹配

在以下示例中,对于 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. Portal 设置 |目录 + 订阅,在 “目录名称 ”列表中,找到 Azure AD B2C 目录。
  4. 选择“ 切换”。
  5. 在 Azure 门户中,搜索并选择 Azure AD B2C
  6. 在“策略”下,选择“ 标识体验框架”。
  7. 选择“ 上传自定义策略”。
  8. 按以下顺序上传更改的两个策略文件:
  • 扩展策略,例如 TrustFrameworkExtensions.xml
  • 信赖方策略,例如 SignUpOrSignin.xml

测试自定义策略

  1. 在 Azure AD B2C 租户中,在 “策略”下,选择“ 标识体验框架”。
  2. Custom policies (自定义策略) 下,选择 AsignioSUSI
  3. 对于 应用程序,请选择已注册的 Web 应用程序。 回复 URLhttps://jwt.ms.
  4. 选择“立即运行”。
  5. 浏览器将重定向到 Asignio 登录页面。
  6. 此时会显示登录屏幕。
  7. 在底部,选择 Asignio 身份验证。

如果您有 Asignio 签名,系统会提示您使用 Asignio 签名进行身份验证。 如果没有,请提供设备电话号码以通过 SMS OTP 进行身份验证。 使用链接注册您的 Asignio 签名。

  1. 浏览器将重定向到 https://jwt.ms。 将显示 Azure AD B2C 返回的令牌内容。

后续步骤