你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用 Azure Active Directory B2C 配置 Trusona Authentication Cloud
本示例教程介绍如何将 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、蓝牙和 OTP)进行身份验证。
在此方案中,Trusona 充当 Azure AD B2C 的标识提供者 (IdP) 来启用无密码身份验证。 以下组件构成了解决方案:
- Azure AD B2C 合并登录和注册策略。
- Trusona Authentication Cloud 作为 IdP 添加到 Azure AD B2C。
步骤 | 说明 |
---|---|
1. | 用户尝试通过其浏览器登录到 Web 应用程序。 |
2. | Web 应用程序重定向到 Azure AD B2C 注册和登录策略。 |
3. | Azure AD B2C 将用户重定向到 Trusona Authentication Cloud OpenID Connect (OIDC) IdP。 |
4. | 用户看到一个登录网页,其中要求提供其用户名–通常是电子邮件地址。 |
5. | 用户输入其电子邮件地址并选择“继续”按钮。 如果在 Trusona Authentication Cloud 中找不到用户的帐户,则会向浏览器发送响应,以在设备上启动 WebAuthn 注册过程。 否则,会将响应发送到浏览器,以开始 WebAuthn 身份验证过程。 |
6. | 系统会要求用户选择要使用的凭据。 该密钥与 Web 应用程序的域名或硬件安全密钥相关联。 用户选择凭据后,OS 会请求用户使用生物识别、密码或 PIN 来确认其身份。 这将解锁安全 Enclave/可信执行环境,它们会生成由与所选凭据相关联的私钥签名的身份验证声明。 |
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 设置中使用。
注意
- Trusona 门户支持自助注册。 注册后,系统会将你分配到具有只读权限的 Trusona 帐户。 之后,Trusona 会根据组织的门户用户访问控制策略将你分配到正确的帐户,并提升读写权限。
- Microsoft Entra ID 的初始域名用作客户端重定向主机。
步骤 2:在 Azure AD B2C 中注册 Web 应用程序
必须先在你的客户租户中注册应用程序,然后这些应用程序才能与 Azure AD B2C 交互。 本教程介绍如何使用 Azure 门户注册 Web 应用程序。 对于像本教程这样的测试目的,需要注册 https://jwt.ms
,这是 Microsoft 拥有的 Web 应用程序,用于显示令牌的已解码内容(令牌的内容绝不会离开浏览器)。
若要在 Azure AD B2C 租户中注册 Web 应用程序,请使用我们新的统一应用注册体验。
登录 Azure 门户。
如果有权访问多个租户,请选择顶部菜单中的“设置”图标,切换到“目录 + 订阅”菜单中的 Azure AD B2C 租户。
在 Azure 门户中,搜索并选择“Azure AD B2C”。
选择“应用注册”,然后选择“新建注册” 。
输入应用程序的“名称”。 例如 jwt ms。
在“支持的帐户类型”下,选择“任何标识提供者或组织目录中的帐户(用于通过用户流对用户进行身份验证)” 。
在“重定向 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 存在以下限制:
- 回复 URL 必须以方案
https
开头,除非使用 localhost 重定向 URL。 - 回复 URL 区分大小写。 其大小写必须与正在运行的应用程序的 URL 路径的大小写匹配。 例如,如果应用程序在其路径中包括
.../abc/response-oidc
,请不要在回复 URL 中指定.../ABC/response-oidc
。 由于 Web 浏览器将路径视为区分大小写,因此在重定向到大小写不匹配的.../ABC/response-oidc
URL 时,可能会排除与.../abc/response-oidc
关联的 cookie。 - 回复 URL 应包括或排除应用程序预期的尾随正斜杠。 例如,
https://contoso.com/auth-response
和https://contoso.com/auth-response/
可能会被视为应用程序中的非匹配 URL。
- 回复 URL 必须以方案
在“权限”下,选择“授予对 openid 和 office_access 权限的管理员许可”复选框。
选择“注册” 。
启用 ID 令牌隐式授权
如果注册此应用,并利用 https://jwt.ms/
配置该应用来测试用户流或自定义策略,则需要在应用注册中启用隐式授权流:
在左侧菜单中的“管理”下,选择“身份验证” 。
在“隐式授权和混合流”下,选中“ID 令牌(用于隐式和混合流)”复选框。
选择“保存”。
步骤 3:在 Azure AD B2C 中将 Trusona Authentication Cloud 配置为 IdP
以 Azure AD B2C 租户的全局管理员身份登录 Azure 门户。
如果有权访问多个租户,请选择顶部菜单中的“设置”图标,切换到“目录 + 订阅”菜单中的 Azure AD B2C 租户。
选择 Azure 门户左上角的“所有服务”,搜索并选择 Azure AD B2C。
导航到“仪表板”>“Azure Active Directory B2C”>“标识提供者”。
选择“标识提供者”。
选择 添加 。
配置 IdP
选择“标识提供者类型”>“OpenID Connect (预览版)”。
填写用于设置 IdP 的表单:
属性 值 元数据 URL https://authcloud.trusona.net/.well-known/openid-configuration
客户端 ID 在 Trusona Authentication Cloud 门户上可用 客户端机密 在 Trusona Authentication Cloud 门户上可用 范围 OpenID 配置文件电子邮件 响应类型 code 响应模式 form_post 选择“确定”。
选择“映射此标识提供者的声明”。
填写用于映射 IdP 的表单:
属性 值 UserID sub 显示名称 nickname 给定名称 given_name Surname family_name 响应模式 电子邮件 选择“确定”以完成新 OIDC IdP 的设置。
步骤 4:创建用户流策略
现在,你应该会看到 Trusona 作为新 OpenID Connect 标识提供者列出在 B2C IdP 中。
在 Azure AD B2C 租户中的“策略”下,选择“用户流”。
选择“新建用户流”。
依次选择“注册并登录”、版本、“创建”。
为策略输入一个“名称”。
在“标识提供者”部分,选择新创建的“Trusona Authentication Cloud-标识提供者”。
注意
由于 Trusona 本质上采用的是多重身份验证,因此最好是让多重身份验证保持禁用状态。
选择“创建” 。
在“用户特性和声明”下,选择“显示更多”。 在表单中,选择在前面部分的设置标识提供者过程中指定的至少一个特性。
选择“确定”。
步骤 5:测试用户流
选择你创建的策略。
选择“运行用户流”,然后选择设置:
a. 应用程序:选择已注册的应用,例如 jwt ms。
b. 回复 URL:选择重定向 URL,例如
https://jwt.ms
。选择“运行用户流”。 系统会将你重定向到 Trusona Authentication Cloud。 用户看到一个登录网页,其中要求提供其用户名–通常是电子邮件地址。 如果在 Trusona Authentication Cloud 中找不到用户的帐户,则会向浏览器发送响应,以在设备上启动 WebAuthn 注册过程。 否则,会将响应发送到浏览器,以开始 WebAuthn 身份验证过程。 系统会要求用户选择要使用的凭据。 该密钥与 Web 应用程序的域名或硬件安全密钥相关联。 用户选择凭据后,OS 会请求用户使用生物识别、密码或 PIN 来确认其身份。 这将解锁安全 Enclave/可信执行环境,它们会生成由与所选凭据相关联的私钥签名的身份验证声明。 Azure AD B2C 会验证 Trusona 身份验证响应并颁发 OIDC 令牌。 它将用户重定向回发起的应用程序,例如
https://jwt.ms
,该应用程序会显示 Azure AD B2C 返回的令牌的内容。
步骤 3:创建 Trusona Authentication Cloud 策略密钥
存储之前在步骤 1 的 Azure AD B2C 租户中记录的客户端密码。
登录 Azure 门户。
如果有权访问多个租户,请选择顶部菜单中的“设置”图标,切换到“目录 + 订阅”菜单中的 Azure AD B2C 租户。
选择 Azure 门户左上角的“所有服务”,然后搜索并选择“Azure AD B2C” 。
在“概述”页上选择“标识体验框架”。
选择“策略密钥”,然后选择“添加”。
对于“选项”,选择“手动”。
输入策略密钥的名称。 例如,
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 使用这些声明来验证特定用户是否已使用其设备上可用的密钥或硬件安全密钥进行身份验证,从而证明用户的身份。
使用以下步骤将 Trusona 添加为声明提供程序:
从 GitHub 获取自定义策略新手包,然后使用 Azure AD B2C 租户名称更新 LocalAccounts 新手包中的 XML 文件:
下载 .zip 文件或克隆存储库:
git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
在 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>
用你之前在步骤 1 中记录的 Trusona Authentication Cloud 应用程序 ID 设置 client_id。
使用步骤 3 中创建的策略密钥的名称更新 client_secret 部分。 例如,
B2C_1A_TrusonaTacClientSecret
:<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
保存更改。
步骤 5:添加用户旅程
此时,你已设置了 IdP,但它尚未出现在任何登录页中。 如果你有自己的自定义用户旅程,请继续执行步骤 6,否则,请创建现有模板用户旅程的副本,如下所示:
从初学者包中打开
LocalAccounts/TrustFrameworkBase.xml
文件。找到并复制包含
Id=SignUpOrSignIn
的 UserJourney 元素的完整内容。打开
LocalAccounts/TrustFrameworkExtensions.xml
并找到 UserJourney元素。 如果该元素不存在,请添加一个。将复制的 UserJourney 元素的完整内容粘贴为 UserJourneys 元素的子级。
对用户旅程的
Id
进行重命名。 例如,Id=TrusonaTacSUSI
。
步骤 6 - 将 IdP 添加到用户旅程
目前你已拥有用户旅程,请将新的 IdP 添加到用户旅程。
在用户旅程中,查找包含
Type=CombinedSignInAndSignUp
或Type=ClaimsProviderSelection
的业务流程步骤元素。 这通常是第一个业务流程步骤。 ClaimsProviderSelections 元素包含用户可以用来登录的 IdP 列表。 元素的顺序将决定向用户显示的登录按钮的顺序。 添加 ClaimsProviderSelection XML 元素。 将 TargetClaimsExchangeId 的值设置为易记名称,例如TrusonaTacExchange
。在下一个业务流程步骤中,添加 ClaimsExchange 元素。 将 ID 设为目标声明交换 ID 的值。 将 TechnicalProfileReferenceId 的值更新为先前添加声明提供程序时创建的技术配置文件的 ID,例如
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,使其与已在其中添加标识提供者的用户旅程 ID 匹配。
在以下示例中,对于 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 门户。
如果有权访问多个租户,请选择顶部菜单中的“设置”图标,切换到“目录 + 订阅”菜单中的 Azure AD B2C 租户。
在 Azure 门户中,搜索并选择 Azure AD B2C。
在策略下,选择 Identity Experience Framework。
选择“上传自定义策略”,然后上传已更改的两个策略文件,其顺序为:先上传扩展策略(例如
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。 用户看到一个登录网页,其中要求提供其用户名–通常是电子邮件地址。 如果在 Trusona Authentication Cloud 中找不到用户的帐户,则会向浏览器发送响应,以在设备上启动 WebAuthn 注册过程。 否则,会将响应发送到浏览器,以开始 WebAuthn 身份验证过程。 系统会要求用户选择要使用的凭据。 该密钥与 Web 应用程序的域名或硬件安全密钥相关联。 用户选择凭据后,OS 会请求用户使用生物识别、密码或 PIN 来确认其身份。 这将解锁安全 Enclave/可信执行环境,它们会生成由与所选凭据相关联的私钥签名的身份验证声明。
如果登录过程是成功的,则你的浏览器会被重定向到
https://jwt.ms
,其中显示 Azure AD B2C 返回的令牌内容。
后续步骤
有关更多信息,请查看以下文章: