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

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

项目
01/26/2024

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

准备阶段

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

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

在本文中，每种方法的步骤都各不相同。

了解详细信息：

先决条件

Azure 订阅。
如果没有，请获取一个 Azure 免费帐户

一个关联到 Azure 订阅的 Azure AD B2C 租户
请参阅教程：创建 Azure Active Directory B2C 租户
由 Asignio 颁发的 Asignio 客户端 ID 和客户端密码。
可通过向 Asignio 注册移动或 Web 应用程序来获取这些令牌。

对于自定义策略

完成教程：在 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 签名，则可以使用短信一次性密码 (OTP) 进行身份验证。完成身份验证后，用户会收到注册链接以创建其 Asignio 签名。
用户使用 Asignio 签名和面部验证或者语音和面部验证进行身份验证。
质询响应发送到 Asignio。
Asignio 返回对 Azure AD B2C 登录的 OIDC 响应。
Azure AD B2C 向 Asignio 发送身份验证验证请求，以确认收到身份验证数据。
系统将授权或拒绝用户访问应用程序。

为应用程序配置 Asignio

为应用程序配置 Asignio 需要使用 Asignio 合作伙伴管理站点。

转到 asignio.com Asignio 合作伙伴管理页面，为组织请求访问权限。
使用凭据登录到 Asignio 合作伙伴管理站点。
使用 Azure AD B2C 租户为 Azure AD B2C 应用程序创建记录。 Azure AD B2C 与 Asignio 一起使用时，Azure AD B2C 管理连接的应用程序。 Asignio 应用代表 Azure 门户中的应用。
在 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 应用程序并启用 ID 令牌隐式授权

完成教程：在 Azure Active Directory B2C 中注册 Web 应用程序

将 Asignio 配置为 Azure AD B2C 中的标识提供者

在以下说明中，请将 Microsoft Entra 租户与 Azure 订阅配合使用。

以 Azure AD B2C 租户的全局管理员身份登录到 Azure 门户。
在 Azure 门户工具栏中，选择“目录 + 订阅”。
在“门户设置 | 目录 + 订阅”上的“目录名称”列表中，找到 Microsoft Entra 目录。
选择“切换”。
在 Azure 门户左上角，选择“所有服务”。
搜索并选择“Azure AD B2C”。
在 Azure 门户中，搜索并选择“Azure AD B2C”。
在左侧菜单中，选择“标识提供者”。
选择“新的 OpenID Connect 提供程序”
选择“标识提供者类型”>“OpenID Connect”。
在“名称”中，输入 Asignio 登录名或所选名称。
对于“元数据 URL”，请输入 https://authorization.asignio.com/.well-known/openid-configuration。
在“客户端 ID”中，输入生成的客户端 ID。
在“客户端密码”中，输入生成的客户端密码。
“范围”使用“OpenID 电子邮件配置文件”。
对于“响应类型”，请选择“代码”。
“响应模式”使用“query”。
“域提示”使用 https://asignio.com。
选择“确定” 。
选择“映射此标识提供者的声明”。
“用户 ID”使用 sub。
“显示名称”使用“name”。
“名字”使用“given_name”。
“姓氏”使用 family_name。
“电子邮件”使用“email”。
选择“保存” 。

创建用户流策略

在 Azure AD B2C 租户中的“策略”下，选择“用户流”。
选择“新建用户流”。
选择“注册和登录”用户流类型。
选择“推荐版本”。
选择“创建” 。
在“名称”中输入用户流名称，例如 AsignioSignupSignin。
在“标识提供者”下，对于“本地帐户”，选择“无”。此操作会禁用电子邮件和密码身份验证。
在“自定义标识提供者”中，选择创建的 Asignio 标识提供者。
选择“创建” 。

测试用户流

在 Azure AD B2C 租户中，选择“用户流” 。
选择创建的用户流。
对于“应用程序”，请选择注册的 Web 应用程序。 回复 URL 为 https://jwt.ms。
选择“运行用户流”。
浏览器会重定向到 Asignio 登录页面。
此时会显示登录屏幕。
在底部，选择“Asignio”身份验证。

如果有 Asignio 签名，请根据提示完成身份验证。如果没有，请提供手机号，以便通过短信 OTP 进行身份验证。使用链接注册 Asignio 签名。

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

创建 Asignio 策略密钥

在 Azure AD B2C 租户中存储生成的客户端密码。
登录 Azure 门户。
在门户工具栏中，选择“目录 + 订阅”。
在“门户设置 | 目录 + 订阅”上的“目录名称”列表中，找到 Azure AD B2C 目录。
选择“切换”。
在 Azure 门户左上角，选择“所有服务”。
搜索并选择“Azure AD B2C”。
在“概述”页上选择“标识体验框架”。
选择“策略密钥”。
选择添加。
对于“选项”，请选择“手动” 。
输入策略密钥的名称。前缀 B2C_1A_ 会附加到密钥名称。
在“机密”中，输入前面记下的客户端密码。
对于“密钥用法”，请选择“签名” 。
选择“创建”。

将 Asignio 配置为标识提供者

提示

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

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

将 Asignio 添加为声明提供程序

从 GitHub 获取自定义策略新手包，然后使用 Azure AD B2C 租户名称更新 LocalAccounts 新手包中的 XML 文件：

下载 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">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>

将 client_id 设置为记录的 Asignio 应用程序 ID。
使用创建的策略密钥更新“client_secret”部分。例如，B2C_1A_AsignioSecret：
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
保存更改。

添加用户旅程

标识提供者不在登录页面上。

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

了解详细信息：用户旅程

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

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

在用户旅程中，查找包含 Type=CombinedSignInAndSignUp 或 Type=ClaimsProviderSelection 的业务流程步骤元素。这通常是第一个业务流程步骤。 ClaimsProviderSelections 元素具有用户登录使用的标识提供者列表。元素顺序控制登录按钮的顺序。
添加 ClaimsProviderSelection XML 元素。
将 TargetClaimsExchangeId 的值设置为易记名称。
添加 ClaimsExchange 元素。
将 ID 设为目标声明交换 ID 的值。
将 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 执行的用户旅程。

在信赖方中，找到 DefaultUserJourney 元素。
更新 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>

上传自定义策略

登录 Azure 门户。
在门户工具栏中，选择“目录 + 订阅”。
在“门户设置 | 目录 + 订阅”上的“目录名称”列表中，找到 Azure AD B2C 目录。
选择“切换”。
在 Azure 门户中，搜索并选择“Azure AD B2C”。
在策略下，选择 Identity Experience Framework。
选择“上传自定义策略”。
按以下顺序上传已更改的两个策略文件：

扩展策略，例如 TrustFrameworkExtensions.xml
信赖方策略，例如 SignUpOrSignin.xml

测试自定义策略

在 Azure AD B2C 租户中的“策略”下选择“Identity Experience Framework”。
在“自定义策略”下，选择“AsignioSUSI”。
对于“应用程序”，请选择你注册的 Web 应用程序。 回复 URL 为 https://jwt.ms。
选择“立即运行”。
浏览器会重定向到 Asignio 登录页面。
此时会显示登录屏幕。
在底部，选择“Asignio”身份验证。

如果已有 Asignio 签名，系统会提示你使用它进行身份验证。如果没有，请提供手机号，以便通过短信 OTP 进行身份验证。使用链接注册 Asignio 签名。

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

通过