Azure Ad b2c: Get email in Claims after successfully Signin in azure ad b2c

Question

I am using starter pack of custom polices with SocialAndLocalAccounts pack.

It is working fine for me.

But I am facing one issue.I need to get email as claim after successfully login. I am getting email as claim, once user has been been signed-up and redirects back immediately to application.

but I am not getting it when a user simply signs-in.

How can I get that? where do I need to write an Output Claim to get the value of email in claim?

Kindly help me. Thanks

Answer 1

For Chris Padgett's answer, you can add other emails (Alternate email) into the claim.

If you just want to add email claim from the SignIn name into the token, you can just take following steps:

1. Open your SignUporSignIn.xml file

2. Replace <OutputClaim ClaimTypeReferenceId="email" /> with <OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" PartnerClaimType="email" />

3. Save this SignUporSignIn.xml file and upload it to Azure AD B2C to overwrite the policy.

4. Run the SignUporSignIn policy to test it. Here is my test result, you can see the email claim in the token:

Hope this helps.

Answer 2

Following describes how you can save, load, and then issue the otherMails claim as emails from the sign-up/sign-in and password reset policies.

When writing a local account: You must create the otherMails claim from the email claim using the CreateOtherMailsFromEmail claims transformation and then persist the otherMails claim in the AAD-UserWriteUsingLogonEmail technical profile:

<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
  ...
  <IncludeInSso>false</IncludeInSso>
  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="CreateOtherMailsFromEmail" />
  </InputClaimsTransformations>
  <InputClaims>
    ...
  </InputClaims>
  <PersistedClaims>
    ...
    <PersistedClaim ClaimTypeReferenceId="otherMails" />
  </PersistedClaims>
  <OutputClaims>
    ...
    <OutputClaim ClaimTypeReferenceId="otherMails" />
  </OutputClaims>
  ...
</TechnicalProfile>

You must then pass the otherMails claim out from the LocalAccountSignUpWithLogonEmail technical profile that is invoked to register a local account:

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

When writing a social account: The otherMails claim is already created from the email claim and then persisted in the AAD-UserWriteUsingAlternativeSecurityId technical profile.

You must then pass the otherMails claim out from the SelfAsserted-Social technical profile that is invoked to register a social account:

<TechnicalProfile Id="SelfAsserted-Social">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

When reading a local or social account: The otherMails claim is already read in the AAD-UserReadUsingObjectId, AAD-UserReadUsingEmailAddress, and AAD-UserReadUsingAlternativeSecurityId technical profiles.

You must then pass the otherMails claim out from the LocalAccountDiscoveryUsingEmailAddress technical profile that is invoked to recover a local password:

<TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
    ...
    <OutputClaims>
        ...
        <OutputClaim ClaimTypeReferenceId="otherMails" />
    </OutputClaims>
</TechnicalProfile>

To issue the otherMails claim as emails from the sign-up/sign-in and password reset policies: You must add the otherMails claim as <OutputClaim /> to the relying party policies:

<RelyingParty>
    ...
    <TechnicalProfile Id="PolicyProfile">
        <OutputClaims>
            ...
            <OutputClaim ClaimTypeReferenceId="otherMails" PartnerClaimType="emails" />
        </OutputClaims>
    </TechnicalProfile>
</RelyingParty>

Answer 3

Another option that is working for me was to extend AAD-UserReadUsingObjectId so that it copies the signInNames.emailAddress claim into email. That brought sign-in into alignment with our other journeys/sub-journeys for integrated sign-up, password reset, and social log-in -- which each populate email during first log-in/sign-up.

All I needed to do was add this to TrustFrameworkExtension.xml (under <ClaimsProviders>):

    <ClaimsProvider>
      <DisplayName>Azure Active Directory</DisplayName>

      <TechnicalProfiles>
        <TechnicalProfile Id="AAD-UserReadUsingObjectId">
          <OutputClaims>
            <OutputClaim 
              ClaimTypeReferenceId="email"
              PartnerClaimType="signInNames.emailAddress"
            />
          </OutputClaims>
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>