Azure AD B2C Sign-Up w/no user entry

Question

I've set up Azure AD B2C to allow authentication by users from a "regular" AAD directory using custom policies as described here https://learn.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

score 4 · Accepted Answer · answered Jan 16 '18 at 20:41

4

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).

answered Jan 16 '18 at 20:41

Chris Padgett

14,186
1
15
28

If I do that, do I also keep Step 5 (_AADUserReadWithObjectId_) and Step 6 (a repeated _AAD-UserWriteUsingAlternativeSecurityId_) ? – M Herbener Jan 16 '18 at 21:54
1

Ok, I replaced my orchestration step 4 with a simplified version of what you recommended (leaving out the preconditions because I am willing to assume in this userjourney that the object doesn't exist yet), removed my steps 5 and 6, and relabeled step 7 to step 5, and it worked as desired. I thought I had tried that before but apparently not. thanks! – M Herbener Jan 16 '18 at 22:17
In fact, in my scenario I can even leave out orchestration step 3 (_AADUserReadUsingAlternativeSecurityId_) because I'm willing to assume the user object won't already exist. – M Herbener Jan 16 '18 at 22:29
If you can accept that, then yes you can remove step 3 and preconditions for step 4. – Chris Padgett Jan 16 '18 at 23:31

Azure AD B2C Sign-Up w/no user entry

1 Answers1