Question

试图使B2C TOTP示例正常工作，并且在上传自定义策略文件时遇到问题。（github仓库在这里：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.microsoft”的策略“ B2C_1A_TOTP_TrustFrameworkExtensions”中的用户旅程“ SignUpOrSignIn”。 ”具有包含2个声明交换的步骤5。必须先选择一个声明提供者，才能确定可以使用哪个声明交换。租户“ ______test.onmicrosoft.com”的策略“ B2C_1A_TOTP_TrustFrameworkExtensions”中的用户旅程“ SignUpOrSignIn”具有步骤具有2个权利要求交换的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

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

Azure AD B2C TOTP示例

1 个答案: