1

Based on this question... the REST API endpoint is validating the external IDP email and is correclty returning an error back in the case the email is not valid.

return Content(HttpStatusCode.Conflict, new CustomResponseContent
{
    Version = "1.0.0",
    Status = (int)HttpStatusCode.Conflict,
    UserMessage = message
});

Now I'd like to detect this error and use it in a subsequent OrchestrationStep like this:

<OrchestrationStep Order="3" 
  Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="REST-ValidateSignInEmail" 
      TechnicalProfileReferenceId="REST-ValidateSignInEmail" />
  </ClaimsExchanges>
</OrchestrationStep>

<!-- Taken from here: https://medium.com/the-new-control-plane/creating-an-error-page-for-an-azure-ad-b2c-custom-policy-flow-fb2692a3b50f -->
<OrchestrationStep Order="4" 
  Type="ClaimsExchange">
  <Preconditions>
    <Precondition Type="ClaimEquals" 
      ExecuteActionsIf="true">
      <Value>extension_Flag</Value>
      <Value>False</Value>
      <Action>SkipThisOrchestrationStep</Action>
    </Precondition>
  </Preconditions>
  <ClaimsExchanges>
    <ClaimsExchange Id="SelfAssertedRegError" 
      TechnicalProfileReferenceId="SelfAsserted-RegError" />
  </ClaimsExchanges>
</OrchestrationStep>

If step 3 returns a conflict, I'd like to show the error message in step 4 using the custom error page implemented as described here.

I see that step 4 executes based on extension_Flag.

Is there any way I could retrieve and store the result from REST-ValidateSignInEmail and use it in the flag for step 4?

Note: when the user journey finishes executing I see the following AADB2C error in the URL. It comes from the REST API endpoint error (409 - Conflict)...

https://mywebsite.azurewebsites.net/#error=server_error&error_description=AADB2C%3a+user%40gmail.com+is+not+valid.%0d%0aCorrelation+ID%7a+7777f77-7afd-7777-a777-7c77b7e77b7b%0d%0aTimestamp%7a+2019-11-09+14%3a40%3a57Z%0d%0a&state=7777c77a-77ad-414a-84df-3c131ed81ba7

The error_description message is what I'd like to pass to step 4.

Leniel Maccaferri
  • 100,159
  • 46
  • 371
  • 480

1 Answers1

3

I did this in a different way... instead of returning a Conflict [409] status, I changed the REST endpoint to return an OutputClaim like this:

<OutputClaims>
    <OutputClaim ClaimTypeReferenceId="extension_isEnabled" 
        PartnerClaimType="IsEnabled" DefaultValue="false"/>
    <OutputClaim ClaimTypeReferenceId="errorMessage" 
        PartnerClaimType="ErrorMessage"/>
</OutputClaims>

This way I have a claim to check on step 4. Note that I also return an errorMessage from the endpoint. This error message will be later passed to SelfAsserted-RegError Technical Profile.

Depending on the validation done in the back-end, extension_isEnabled will get True or False.

On step 4 we check extension_isEnabled:

<OrchestrationStep Order="4" 
                   Type="ClaimsExchange">
    <Preconditions>
        <Precondition Type="ClaimEquals" 
                      ExecuteActionsIf="true">
            <Value>extension_isEnabled</Value>
            <Value>True</Value>
            <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
    </Preconditions>
    <ClaimsExchanges>
         <ClaimsExchange Id="SelfAssertedRegError" 
                         TechnicalProfileReferenceId="SelfAsserted-RegError" />
    </ClaimsExchanges>
</OrchestrationStep>

Step 4 will only be executed when extension_isEnabled is false. If it is true we SkipThisOrchestrationStep and the SelfAsserted-RegError Technical Profile won't be called at all. The UserJourney flow continues as expected.

Leniel Maccaferri
  • 100,159
  • 46
  • 371
  • 480