Azure AD B2C pre-populate a custom attribute in the SignUp policy

7
votes

Does Azure AD B2C support pre-populating a custom attribute in the SignUp Policy when called from the Web application (ASP.Net MVC)?

We can create a custom SignUp attribute but we weren't able to find a specification in the documentation how to pass value to populate the custom attribute. If this is not supported out of the box, does anybody found a workaround?

Here are some more details for the context in case somebody has faced a similar scenario and found a useful solution:

We explore the options to solve the following scenario with Azure AD B2C: a registered user invites another person to signup to the application by sending an invitation email which has the url to the application’s login page along with a special invitation code(guid) as a query param, so it can click on the link and to be redirected to the Signup page. After the invited person creates an account, we need to use the code in order to associate the newly created user to the user who sent the invitation.

Currently this is implemented in the ASP.Net using the default identity provider (storing the user data in database with AspNet... tables). With replacing the local identity provider with the Azure AD B2C, we are loosing the context during the round-trip to the Azure AD B2C Signup page. The user clicks on the link on the email and gets to the SIgnUp page but the invitation code is not pre-populated.

1
azure-ad-b2c
Welcome to Stack Overflow. What have you already tried yourself to do this? Please review How do I ask a good question. Stack Overflow is not a coding service. You are expected to research your issue and make a good attempt to write the code yourself before posting. If you get stuck on something specific, come back and include a Minimal, Complete, and Verifiable example and a summary of what you tried, so we can help. – FluffyKitten
@FluffyKitten what is not specific about that? The first sentence is a very specific question. And a good question I might add :) Regards, Mike D. – spottedmahn
@spottedmahn The question has been edited since my comment. But just being specific on its own isn't enough - see the rest of requirements in my initial comment. – FluffyKitten
@FluffyKitten I see, thanks for letting me know :) – spottedmahn

1 Answers

10
votes

A working sample of an invitation flow is here.

In the WingTipGamesWebApplication project, the InvitationController controller class has two action methods, Create and Redeem.

The Create action method sends a signed redemption link to the email address for the invited user. This redemption link contains this email address. It could also contain the invitation code.

The Redeem action method handles the redemption link. It passes the email address, as the verified_email claim in a JWT that is signed with the client secret of the Wingtip Games application (see the CreateSelfIssuedToken method in the Startup class in the WingTipGamesWebApplication project), from the redemption link to the Invitation policy. It could also pass the invitation code.

The Invitation policy can be found at here.

The Invitation policy declares the verified_email claim as an input claim:

<RelyingParty>
  <DefaultUserJourney ReferenceId="Invitation" />
  <TechnicalProfile Id="Invitation">
    <InputTokenFormat>JWT</InputTokenFormat>
      <CryptographicKeys>
        <Key Id="client_secret" StorageReferenceId="WingTipGamesClientSecret" />
    </CryptographicKeys>
    <InputClaims>
      <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
    </InputClaims>
  </TechnicalProfile>
</RelyingParty>

The extension_verifiedEmail claim type, which is declared as a read-only field (so that it can't be modified by the end user), is mapped to the verified_email input claim:

<BuildingBlocks>
  <ClaimsSchema>
    <ClaimType Id="extension_VerifiedEmail">
      <DisplayName>Verified Email</DisplayName>
      <DataType>string</DataType>
      <DefaultPartnerClaimTypes>
        <Protocol Name="OAuth2" PartnerClaimType="verified_email" />
        <Protocol Name="OpenIdConnect" PartnerClaimType="verified_email" />
        <Protocol Name="SAML2" PartnerClaimType="http://schemas.wingtipb2c.net/identity/claims/verifiedemail" />
      </DefaultPartnerClaimTypes>
      <UserInputType>Readonly</UserInputType>
    </ClaimType>
  </ClaimsSchema>
</BuildingBlocks>

The Invitation user journey can be found in here.

The second orchestration step of the Invitation user journey executes the LocalAccount-Registration-VerifiedEmail technical profile:

<UserJourney Id="Invitation">
  <OrchestrationSteps>
    ...
    <OrchestrationStep Order="2" Type="ClaimsExchange">
      <ClaimsExchanges>
        ...
        <ClaimsExchange Id="LocalAccountRegistrationExchange" TechnicalProfileReferenceId="LocalAccount-Registration-VerifiedEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>
  </OrchestrationSteps>
</UserJourney>

The LocalAccount-Registration-VerifiedEmail technical profile registers the local account with the verified email address:

<TechnicalProfile Id="LocalAccount-Registration-VerifiedEmail">
  <DisplayName>WingTip Account</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="ContentDefinitionReferenceId">api.localaccount.registration</Item>
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
    <Item Key="language.button_continue">Create</Item>
  </Metadata>
  <CryptographicKeys>
    <Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" />
  </CryptographicKeys>
  <InputClaimsTransformations>
    <InputClaimsTransformation ReferenceId="CreateEmailFromVerifiedEmail" />
  </InputClaimsTransformations>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="extension_VerifiedEmail" Required="true" />
    <OutputClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
    <OutputClaim ClaimTypeReferenceId="displayName" Required="true" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="localAccountAuthentication" />
    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
    <OutputClaim ClaimTypeReferenceId="newUser" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="sub" />
    <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SSOSession-AzureActiveDirectory" />
</TechnicalProfile>

Before the local account is registered by the AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExists validation technical profile, the CreateEmailFromVerifiedEmail claims transformation copies the verified_email claim to the email claim:

<ClaimsTransformation Id="CreateEmailFromVerifiedEmail" TransformationMethod="FormatStringClaim">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="extension_VerifiedEmail" TransformationClaimType="inputClaim" />
  </InputClaims>
  <InputParameters>
    <InputParameter Id="stringFormat" DataType="string" Value="{0}" />
  </InputParameters>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="email" TransformationClaimType="outputClaim" />
  </OutputClaims>
</ClaimsTransformation>

To save the invitation code against the local account, you must:

  • Add the "extension_InvitationCode" claim to the claims schema
  • Add it as an input claim to the Invitation policy
  • Add it as an input claim to the LocalAccount-Registration-VerifiedEmail technical profile
  • Add it as a persisted claim to the AzureActiveDirectoryStore-WriteUserByEmail-ThrowIfExist technical profile