4
votes

I've set up Azure AD B2C to allow authentication by users from a "regular" AAD directory using custom policies as described here https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom. In one scenario I want the user to do a signup (authenticate using their AAD creds, create the corresponding object in AAD B2C directory, and pass objectidentifier as claim to my application) without providing any further info. Starting from the examples, I can't figure out how to entirely skip the self-assertion step. The two approaches I've tried are

1) removing the SelfAsserted-Social ClaimsExchange, and 2) Modifying (actually, copying into TrustFrameworkExtensions, renaming, and editing) the SelfAsserted-Social and AAD-UserReadUsingObjectId ClaimsExchanges so that the only OutputClaim entries are ones that don't require user prompting.

In both approaches, from a UI perspective the signup appears to work, but no user object is created in the B2C directory. Using App Insights, in both approaches the AAD-UserReadUsingObjectId seems to generate Microsoft.Cpim.Common.PolicyException.

The full user journey is

<UserJourney Id="SignUpAAD">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="KDEWEbAppTestExchange"   />
          </ClaimsProviderSelections>
        </OrchestrationStep>

        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="KDEWebAppTestExchange" TechnicalProfileReferenceId="KDEWebAppTestProfile" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <OrchestrationStep Order="3" Type="ClaimsExchange">
           <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>

         <!-- prepare ground for searching for user -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social-Silent" TechnicalProfileReferenceId="SelfAsserted-Social-Silent" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent 
          in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectIdLimited" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- 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="6" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>

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

      </OrchestrationSteps> 
    </UserJourney>

Any ideas?

thanks

Martin

1

1 Answers

4
votes

You have to replace orchestration step 4 with the following orchestration step:

<OrchestrationStep Order="4" Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
      <Value>objectId</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="AAD-UserWriteUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
  </ClaimsExchanges>
</OrchestrationStep>

This orchestration step creates a user object if the user object wasn't retrieved at orchestration step 3 (i.e. the "objectId" claim doesn't exist).