0

Trying to get the B2C TOTP sample working and having issues uploading the custom policy files. (github repo here: github azure b2c totp sample)

I started with the TrustFrameworkBase.xml from the SocialAndLocalAccounts policy starter pack. Added my tenant in the appropriate places and uploaded - success. Next the TrustFrameworkExtensions.xml from the github repo - created the WebApp-GraphAPI-DirectoryExtensions application as indicated in the docs - plus the IdentityExperienceFramework app and the ProxyIdentityExperienceFramework app. Placed the ID's in the appropriate places in the extensions policy file and uploaded it - I receive the following error:

Validation failed: 2 validation error(s) found in policy "B2C_1A_TOTP_TRUSTFRAMEWORKEXTENSIONS" of tenant "______test.onmicrosoft.com".User journey "SignUpOrSignIn" in policy "B2C_1A_TOTP_TrustFrameworkExtensions" of tenant ""______test.onmicrosoft.com" has step 5 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.User journey "SignUpOrSignIn" in policy "B2C_1A_TOTP_TrustFrameworkExtensions" of tenant "______test.onmicrosoft.com" has step 6 with 2 claims exchanges. It must be preceded by a claims provider selection in order to determine which claims exchange can be used.

Any pointers as to what I am missing?

Added SignUpOrSignIn user journey as requested:

<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>
pshoey
  • 11
  • 4
  • Could you post the SignUpOrSignIn user journey definition? Also, you could try renaming the user journey because it will most likely be overriding a user journey in the base file if they have the same name. And that has caused very odd issues in the past. – juunas Feb 19 '20 at 06:18
  • i guess my first mistake was to think that one of the samples would actually work!! I'll add the SignUpOrSignIn journey to the original post. – pshoey Feb 19 '20 at 15:34
  • Looking at the journey it definitely sounds like a merge has happened. Could you try changing the journey Id? – juunas Feb 19 '20 at 15:54
  • Renamed it. Now get this error: Validation failed: 1 validation error(s) found in policy "B2C_1A_TOTP_SIGNUP_SIGNIN" of tenant "certificateservices.onmicrosoft.com".Please use page contract in content definitions when enabling JavaScript. I have added :contract to all the datauri values - but I am missing something else? – pshoey Feb 19 '20 at 19:04
  • Changing datauri idpselection to providerselection and adding contract to all the uri's got me past this error - now my new signuporsignin policy generates a different error related to the authentication mode of the AppFactor-GenerateTotpWebHook profile - needing to set AllowInsecureAuthInProduction to true - i'll research this a little - thanks for your help – pshoey Feb 19 '20 at 20:12

1 Answers1

2

This happens when you have 2 user journeys with the same Id.

Jas Suri - MSFT
  • 10,605
  • 2
  • 10
  • 20