Question

我们当前正在使用Azure B2C通过React.js应用程序进行身份验证。我们正在使用的库是msal.js。

最初，我们使用的是启用了SSO的标准用户流，并且msaljs库可以正常运行（并且仍然可以运行）。在该应用程序流程中，对B2C的第一次调用将要求输入id_token，然后在iframe中发起第二个调用，该调用由于用户已经登录而自动起作用。这将自动发生，并且用户只会看到自己正在登录没有任何问题。在这种情况下，在iframe中进行身份验证的调用将使用access_token返回302返回我们的应用，以访问我们的API。

我们现在已切换到自定义策略，以自定义登录页面并使用javascript。这是使用自定义策略设置的，并且可以正确使用多因素身份验证进行登录。流程如下：

msal.js对B2C（/ authorize）调用的首次调用请求一个id_token，并正确遵循流程以使用户登录。
对B2C的第二次调用（/ authorize）也在iframe中完成，但是它没有返回302，而是返回了200，由于（从B2C发送的标头中包含了X- Frame-Options：deny标头
MSAL等待6秒钟以使iframe返回，但由于不成功，因此启动了重定向到访问令牌的登录页面的操作，该重定向有效，但要求用户登录两次。

这是所有情况（我想），因为SSO无法与自定义策略一起正常工作。在第一种情况下，如果有来自B2C的用户流，SSO将启动并使用访问令牌将用户自动重定向回应用程序；在第二种情况下，由于SSO无法正常工作，用户必须登录两次。

我的自定义策略如下所示，它是基于（非常稀疏）文档中提供的B2C自定义策略的示例构建的：

存在一个技术资料，如下所示：

<TechnicalProfile Id="SM-AAD">
  <DisplayName>Session Mananagement Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <PersistedClaims>
    <PersistedClaim ClaimTypeReferenceId="objectId" />
    <PersistedClaim ClaimTypeReferenceId="signInName" />
    <PersistedClaim ClaimTypeReferenceId="authenticationSource" />
    <PersistedClaim ClaimTypeReferenceId="identityProvider" />
    <PersistedClaim ClaimTypeReferenceId="newUser" />
    <PersistedClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" />
  </PersistedClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
  </OutputClaims>
</TechnicalProfile>

用于将信息读取和写入目录的每个技术资料都引用该技术资料，例如。

<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
  ...
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

在我的配置文件（SignUpOfSignIn.xml）中，以下内容如下

<UserJourneyBehaviors>
  <SingleSignOn Scope="Tenant" KeepAliveInDays="7" />
  <SessionExpiryType>Absolute</SessionExpiryType>
  <SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
  <ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>

在我的针对该自定义策略的UserJourney中，每个业务流程步骤均指一个技术概要文件，其中包括用于Session管理的SM-AAD技术概要文件，但PhoneFactor除外（后者使用了自己的SM-MFA技术概要文件，将isActiveMfaSession设置为true）

尽管如此，我仍无法使SSO与自定义配置文件一起正常工作。我注意到的一件事是未使用SSO概要文件中的ClaimType“ objectIdFromSession”。我本以为可以用来确定是否应跳过业务流程步骤，对吗？

对于可能出什么问题的其他帮助或提示，将不胜感激。

为什么SSO对于Azure AD B2C自定义策略无法正常工作

0 个答案: