Azure AD B2C TOTP 示例

Question

尝试使 B2C TOTP 示例正常工作，但在上传自定义策略文件时遇到问题。 （这里的github repo：github azure b2c totp sample）

我从 SocialAndLocalAccounts 策略启动包中的 TrustFrameworkBase.xml 开始。在适当的地方添加我的租户并上传 - 成功。接下来，来自 github 存储库的 TrustFrameworkExtensions.xml - 如文档中所示创建了 WebApp-GraphAPI-DirectoryExtensions 应用程序 - 加上 IdentityExperienceFramework 应用程序和 ProxyIdentityExperienceFramework 应用程序。将 ID 放在扩展策略文件的适当位置并上传 - 我收到以下错误：

验证失败：在租户“______test.onmicrosoft.com”的策略“B2C_1A_TOTP_TRUSTFRAMEWORKEXTENSIONS”中发现 2 个验证错误。租户“__test.onmicrosoft.com”的策略“B2C_1A_TOTP_TrustFrameworkExtensions”中的用户旅程“SignUpOrSignIn” " 有第 5 步和 2 次索赔交换。必须在选择索赔提供商之前确定可以使用哪个索赔交换。租户 "______test.onmicrosoft.com" 的策略 "B2C_1A_TOTP_TrustFrameworkExtensions" 中的用户旅程 "SignUpOrSignIn" 有步骤6 和 2 个声明交换。必须在声明提供者选择之前选择，以确定可以使用哪个声明交换。

关于我缺少什么的任何指针？

根据要求添加了 SignUpOrSignIn 用户旅程：

<UserJourney Id="SignUpOrSignIn">
  <OrchestrationSteps>

    <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
      <ClaimsProviderSelections>
        <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange" />
        <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="FacebookExchange" TechnicalProfileReferenceId="Facebook-OAUTH" />
        <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- For social IDP authentication, attempt to find the user account in the directory. -->
    <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>

    <!-- 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="5" 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>

    <!-- Demo: The following orchestration step is always executed. 
     This step reads any user attributes that we may not have received when authenticating using ESTS so they 
     include the AppCode MFA attributes 
      in the token. -->
    <OrchestrationStep Order="6" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: The following orchestration step is executed only for unregistered 
    accounts (new created account or if user cancel the sign-up process). 
    It generates a verification app secret key for the user (none interactive step). -->
    <OrchestrationStep Order="7" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
          <Value>extension_StrongAuthenticationAppSecretKey</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AppFactorGenerateTotpWebHook" TechnicalProfileReferenceId="AppFactor-GenerateTotpWebHook" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: The following orchestration step is executed only for unregistered 
    accounts (new created account or if user cancel the sign-up process). 
    It registers a verification app through QR code that mobile authentication app should scan. -->
    <OrchestrationStep Order="8" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
          <Value>strongAuthenticationAppQRCodeBitmap</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AppFactorRegisterExchange" TechnicalProfileReferenceId="AppFactor-Register" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: The following orchestration step is executed only for registered accounts.
    It asks the user to provide the TOTP code and verifies the provided code (using validation technical profile). -->
    <OrchestrationStep Order="9" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
          <Value>strongAuthenticationAppQRCodeBitmap</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="AppFactorChallengeExchange" TechnicalProfileReferenceId="AppFactor-Challenge" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <!-- Demo: The following orchestration step is always executed.
    It updates the verification app time step matched for a given user in the Azure Active Directory.
    An error is raised if the user does not exist. -->
    <OrchestrationStep Order="10" Type="ClaimsExchange">
      <ClaimsExchanges>
        <ClaimsExchange Id="AADWriteUserAppCodeByObjectId" TechnicalProfileReferenceId="AAD-WriteUserAppCodeByObjectId" />
      </ClaimsExchanges>
    </OrchestrationStep>

    <OrchestrationStep Order="11" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

  </OrchestrationSteps>
  <ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>

Answer 1

当您有 2 个具有相同 ID 的用户旅程时会发生这种情况。