Use REST API to external IDP to validate user existence in JIT migration in Azure B2C before creating new AD local account

Question

I am attempting to configure a Sign in to Azure B2C that is designed to check an existing IDP for the user and ADD them as a local account if they currently do not exist as a local account. Basically I want to:

1. Check the local account in B2C to see if they exist (confirmation of matching email is enough)
2. If they exist in the local account, continue to sign them in
3. If they don't yet exist, call a REST API to the external IDP passing the user name (email) and password and validate their authentication.
4. If the call to the external IDP fails, assume they don't exist in either system and prompt them to create an account (which would be local).
5. If the call to the external IDP is successful, create a local account in B2C with their email address and the password they entered.

I think this would be considered a just in time migration. I have taken a look at this read me: https://github.com/azure-ad-b2c/user-migration/blob/master/jit-migration-v2/readme.md and it seems to be what I need. However it seems to be MORE than I need and I am getting lost in the additional details. I really just want to stop with the sign in step for the migration. That sample includes a sign up and password reset flow as well. This post seems close as well: Continue Azure B2C user journey on authentication failure but its so sparse that I cannot tell how complete a solution it would be.

So I am trying to figure out just what is needed for the sign in part of the logic. The sample code in jit-migration-v2 includes 5 XML files. Are all of them needed? Or, better yet, which files in the example would be needed?

It seems there are a LOT of moving parts, I just would like to pare it down to minimum so I can fully understand what is going on and why.

Answer 1

The five files are the standard starter pack.

There are always four flows:

• Password reset
• Profile Edit
• Signup / signin (SUSI)

Plus:

• Base
• Extension

You don't need the reset and edit. You don't need to upload them.

You can change SUSI to just do SU or SI via metadata flags.

The SUSI file is just the RP and basically defines the claims returned in the JWT.

It calls a user journey "SignUpOrSignIn" in the base file so follow that through and you'll see how the flow goes.