Azure AD B2C TOTP样品

Question

试图使B2C TOTP示例正常工作，并存在上载自定义策略文件的问题。(github这里：github天青b2c totp样品)

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

验证失败:在租户的策略"B2C_1A_TOTP_TRUSTFRAMEWORKEXTENSIONS“中发现的2次验证错误--租户的"______test.onmicrosoft.com".User征程"SignUpOrSignIn”中的策略"B2C_1A_TOTP_TrustFrameworkExtensions“中的”______test.onmicrosoft.com“--有步骤5和2次索赔交换。在此之前必须选择索赔提供程序，以确定哪个索赔交换可以是策略“used.User”中的"SignUpOrSignIn“策略中的"B2C_1A_TOTP_TrustFrameworkExtensions”，"______test.onmicrosoft.com“有步骤6，包含两个索赔交换。在此之前必须选择索赔提供程序，以确定可以使用哪种索赔交换。

关于我错过了什么有什么建议吗？

根据请求添加了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

当您有两个具有相同Id的用户行程时，就会发生这种情况。