Delete signInNames.emailAddress from a federated AD B2C user

Question

Hey guys, I am having a hard time trying to delete the signInNames.emailAddress attribute from a federated user using custom policies. I've already tried to remove it by using a technical profile to update the signInNames.emailAddress with a null claim, I've tried to use the DeleteClaims technical profile and the only method I could find to delete it was through the GraphAPI. However, I am not considering this as a solution since I want to delete it from my Custom Policy. Could anyone help, please?

Just to give it more context... Initially, this user is created through GraphAPI as a local user having the signInNames.emailAddress attribute filled. I have a custom policy responsible for merging this pre-registered local user to a federated one and in order to maintain this user as only federated, I would like to remove the signInNames.emailAddress to prevent this user to be able to login using an email and password.

Thanks in advance.

Answer 1

Hello @Alvaro Roberto ,

• Only way I could think of is allowing user attribute to generate a claim with null value. We could achieve this by passing "AllowGenerationOfClaimsWithNullValues" to "Null".
• Within starter pack base profile, the claim attribute signInNames.emailAddress is used in 3 following technical profile: AAD- UserWriteUsingLogonEmail, AAD-UserReadUsingEmailAddress and AAD-UserReadUsingObjectId .
• Kindly try adding <Item Key="AllowGenerationOfClaimsWithNullValues">true</Item> to each of these technical profile metadata and let know if you have any queries in the comments section

Ref example:

           <TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">  
      <Metadata>  
        <Item Key="Operation">Write</Item>  
        <Item Key="RaiseErrorIfClaimsPrincipalAlreadyExists">true</Item>  
        <Item Key="AllowGenerationOfClaimsWithNullValues">true</Item> <!-- ***Allow to generate a claim with null value***. . -->  
      </Metadata>  
      <IncludeInSso>false</IncludeInSso>  
      <InputClaims>  
        <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" />  

        <PersistedClaim ClaimTypeReferenceId="Verified.strongAuthenticationPhoneNumber" PartnerClaimType="strongAuthenticationPhoneNumber" />  

        <!-- Optional claims. -->  
        <PersistedClaim ClaimTypeReferenceId="givenName" />  
        <PersistedClaim ClaimTypeReferenceId="surname" />  
      </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>  

Thanks,
Akshay Kaushik

Please "Accept the answer" ,"Upvote" and rate your experience if the suggestion works as per your business need. This will help us and others in the community as well.