Upskilling on Azure B2C custom policies — Sign Up

tutorial by Twin rizki from the Noun Project

I have organised the series as a list inside Medium so you can see the rest of the series.

If you look at the login page, you see a sign up link.

If you click the link, you see:

The default journey is to verify the email address when you sign up. Recall the second step in the user journey is “LocalAccountSignUpWithLogonEmail”.

Exercise 4

Note: We are going to use the RP “SignUpOrSignInNoFacebookOrMFA”.

This is a much simpler sign up / sign in policy that calls a user journey that just signs up or in, reads the directory and sends a JWT.

If you follow the user journey, you’ll see the steps are:

  • “SelfAsserted-LocalAccountSignin-Email” — to sign in
  • “LocalAccountSignUpWithLogonEmail” — to sign up
  • “AAD-UserReadUsingObjectId” — read the user’s attributes
  • “JwtIssuer” — return the JWT

For the sign up, we trust our users so we don’t need them to verify the email address.

Remove this requirement.

This is where metadata comes in.

Metadata can control the elements of the screen.

<Item Key="EnforceEmailVerification">false</Item>

The TechnicalPolicy (TP) for sign up is “LocalAccountSignUpWithLogonEmail”.

Notice that this is a self asserted TP: “Handler=”Web.TPEngine.Providers.SelfAssertedAttributeProvider”.

This means that it displays a screen, normally for the user to input something.

Copy that TP from the base file to the extension file.

Only keep the elements in the TP that you need and remove the rest.

The elements in the UI that the user is required to enter are controlled by the output claims.

<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
<OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
<OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
<!-- Optional claims, to be collected from the user -->
<OutputClaim ClaimTypeReferenceId="displayName"/>
<OutputClaim ClaimTypeReferenceId="givenName"/>
<OutputClaim ClaimTypeReferenceId="surName"/>

You will see these match the fields in the UI above.

We also want to add an account number to the information collected from the user i.e. in addition to “Display Name”, “Given Name” and “Surname”.

To add a field that is not in the B2C schema (e.g. account number), we use an extension attribute.

(Note the section in the link called “Modify your custom policy”. You need to add the extension attribute keys to the TrustFrameworkExtensions.xml policy.

Add this extension attribute after “surname”.

Lets call it “extension_accountNumber”

When you run the sign up policy, you should see a screen like:

As this is not a standard attribute, you need to add code to write it and read it.

You need to write the extension attribute to B2C at sign up.

“LocalAccountSignUpWithLogonEmail” calls “AAD-UserWriteUsingLogonEmail” so you need to add this TP in order to write the attribute.

Remember that you need to add the extension attribute to the Read TP as well if you want it to be displayed when next you sign in.

Also, add the account number extension attribute to the outputs of the RelyingParty sign in policy

After signing in, you should see something like:

If you are stuck, look here.

If you want to see what’s actually stored in B2C, you can use this utility:

A Console application for Azure AD B2C User Management using the Azure AD Graph

This uses the MSAL library.

All good!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rory Braybrook

Rory Braybrook

NZ Microsoft Identity dude and MVP. Azure AD/B2C/ADFS/Auth0/identityserver. StackOverflow: Presentations: