(cloud compare by iconeu from the Noun Project)

There’s a gotcha with this when you use “ClaimEquals” with B2C custom policies.

Assume you have a claim that you read from B2C e.g. extension_ClaimInB2C and the user types some text into a TextBox e.g. ClaimFromTB and you want to compare the two in a user journey.

Both are defined as strings.

Assume ClaimInB2C = “aaa” and the user types in “aaa” ( = ClaimFromTB).

So something like this is the user journey:

<Precondition Type="ClaimEquals" ExecuteActionsIf="false">

This will not be equal!!!

<Precondition Type="ClaimEquals" ExecuteActionsIf="false">

(Secret account by Wolf Böse from the Noun Project).

This was a request from a customer and on googling it, I found there was nothing!

This could be because secret Q&A are not very secure and have pretty much been deprecated as a security feature.

But sometimes it’s all you have as an option.

NZ is an agricultural country and agriculture and tourism are its biggest income earners. (Well, tourism not so much at the moment 😢)

So we get lots of seasonal and itinerant workers who go from farm to farm picking fruit, pruning the grape vines or whatever.

(Birds by Laymik from the Noun Project)

As most of you know, ADAL is being deprecated.

“Starting June 30th, 2020, we will no longer add new features to ADAL. We’ll continue adding critical security fixes to ADAL until June 30th, 2022. After this date, your apps using ADAL will continue to work, but we recommend upgrading to MSAL to take advantage of the latest features and to stay secure.

Note that your existing apps will continue working without modification. If you’re planning to keep them beyond June 30th, 2022, you should consider updating your apps to MSAL to keep them…

Typically you’ll have a RelyingParty (RP) custom policy that inherits from an extension policy that inherits from a base policy.

This is the way the starter pack is built.

Normally, you would login with an email address but you can also login with a username which is essentially any string of characters e.g. “123456”.

In built in policies, you can configure this on the identity provider but note that this is tenant wide.

This endpoint is part of the OAuth2 specification.

The base article is here.

Following the article, I created a Web application as follows:

This is based on this sample.

Note: there are other phone samples in the samples pack.

This sample shows how to sign up and sign in with a phone.

When you SUSI, you select the country from a drop-down list of country codes and then enter the phone number. An OTP is then sent to the phone that you have to enter to confirm that you own the phone.

This is fine in normal use but I have come across two problems in certain scenarios:

  • The county codes in the custom policy are restricted e.g. to the APAC region and…

The official docs are here.

I based this on the “Sign-up and sign-in with embedded password reset” policy simply because this already had a sub journey within the custom policy.

(BTW. This policy demonstrates how to embed the password reset flow in a part of the sign-up or sign-in policy without the AADB2C90118 error message). Very neat!

“A sub journey is a grouping of orchestration steps that can be invoked at any point within a user journey. You can use sub journeys to create reusable step sequences or implement branching to better represent the business logic”.

i.e. they are a…

Once you have created a B2C tenant, the next step is to run through all the steps in the “Getting Started” doc.

There is now a utility to do this for you!

The utility can be found here.

Rory Braybrook

NZ Microsoft Identity dude and MVP. Azure AD/B2C/ADFS/Auth0/identityserver. StackOverflow: https://bit.ly/2XU4yvJ Presentations: http://bit.ly/334ZPt5

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