Registration with Azure AD B2C custom policy fails due to missing claim information

Question

I am currently investigating the possibilities to send emails from a custom policy in Azure AD B2C through a custom email service provider. To do so, I was following this tutorial from the Microsoft documentation: https://docs.microsoft.com/en-us/azure/active-directory-b2c/custom-email-sendgrid.

Since we have been using custom policies for quite some time now, I tried to adopt the tutorial right away to our own custom policy: we use a multistep registration process with the email verification step being the first and the personal data step being the second step.

My efforts have been successful with connecting the email service provider, sending the code through it and proceed to the second step of the registration process after successfully verifing the email address.

However, when I want to complete the second step of the registration and have the user be actually created in AD I see the following error in the frontend:

Unable to validate the information provided.

To gain further insights I activated developer mode in the policy and checked the traces in Application Insights where I found the following error:

The claim type "signInNames.emailAddress", designated as the identifier claim type, could not be found in the claims collection for the claims principal in tenant id "B2C_1A_signup_notificationtest".

caused in the technical profile AAD-UserWriteUsingLogonEmail. However, as you can see below in that technical profile the aforementioned claim type signInNames.emailAddress is derived throught the partnerClaimType directive in the input claims of the technical profile:

<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
    <Metadata>
        <Item Key="Operation">Write</Item>
        <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>
    </Metadata>
    <IncludeInSso>false</IncludeInSso>
    <InputClaims>
<!-- THIS IS THE LINE I AM REFERRING TO: -->
        <InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress"
                    Required="true"/>
    </InputClaims>
    <PersistedClaims>
        <!-- Required claims -->
        <PersistedClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress"/>
        <PersistedClaim ClaimTypeReferenceId="newPassword" PartnerClaimType="password"/>
        <PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown"/>
        <PersistedClaim ClaimTypeReferenceId="passwordPolicies"
                        DefaultValue="DisablePasswordExpiration"/>

        <!-- Optional claims. -->
        <PersistedClaim ClaimTypeReferenceId="extension_Salutation"/>
        <PersistedClaim ClaimTypeReferenceId="givenName"/>
        <PersistedClaim ClaimTypeReferenceId="surname"/>
        <PersistedClaim ClaimTypeReferenceId="country"/>
        <PersistedClaim ClaimTypeReferenceId="extension_Company"/>
        <PersistedClaim ClaimTypeReferenceId="extension_Kundennummer"/>
    </PersistedClaims>
    <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="objectId"/>
        <OutputClaim ClaimTypeReferenceId="newUser" PartnerClaimType="newClaimsPrincipalCreated"/>
        <OutputClaim ClaimTypeReferenceId="authenticationSource"
                     DefaultValue="localAccountAuthentication"/>
        <OutputClaim ClaimTypeReferenceId="userPrincipalName"/>
        <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress"/>
    </OutputClaims>
    <IncludeTechnicalProfile ReferenceId="AAD-Common"/>
    <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD"/>
</TechnicalProfile> 

So my question would be: where can I look to debug further? Am I looking in the right place or does the error message mean something completely different?

Also as a side note: due to the nature of the identity experience frameworks configuration, there is a lot of xml involved. Therefore I have posted the relying party policy file that also includes the relevant parts for the service connection as a gist here: https://gist.github.com/mmaedler/0a555fc3f9e6036e235a15419e7afdd5

UPDATE Additionally I have added all relevant (hopefully) Technical Profiles as well as the UserJourney itself to this new gist: https://gist.github.com/mmaedler/19ab309897f3a7d993816eb34adc7edb

Also I have used your advise to investigate further. Since I overwrite the Technical Profile LocalAccountSignUpMultiStep-1 to replace the current built in code verification with the one using our mailing backend it suggests the output of this is lacking the email address in a field/format that is expected by the following technical profile in step 2. I have added a new OutputClaim to LocalAccountSignUpMultiStep-2 with a ClaimTypeReferenceId="email" which lead to a new input appearing on registration step 2. Entering an email address there ended in a successful signup and token creation.

Answer 1

Misunderstanding, this XML snippet input claim translates to - "Please find me this user by searching for the email through all users' signInNames.emailAddress attribute".

The error from the log states that, when this lookup operation was performed, the value for signInNames.emailAddress was null. This means that the claim email was never output as an output claim in any previous technical profile called by an orchestration step.

Look back through all technical profiles called prior to this and determine which claim has the user email inside it. Make sure that claim is output by a technical profile that is called by an orchestration step.