AzureFeeds

General notes

The EEID FAQ has some notes:

“More information, including migration plans, will be made available”.

“We’ll provide a migration path for existing custom policies in B2C when it becomes available”.

There is also this Learn article about user migration.

There are several artefacts to migrate:

• Users
• Passwords
• MFA policies, e.g. email, SMS
• User flows
• Custom policies

Users

This can mostly be done via the Graph API.

Note that this does not cater for passwords. You will need to give each user a random password. The user will not be aware of their password.

Passwords

There are two ways to do this.

• Ask the user to SSPR from the EEID login screen once manually migrated
• Do a seamless migration

MFA policies

EEID doesn’t currently support any MFA methods.

TOTP is not regarded as MFA.

User flows

Currently, there is no way to do this.

Custom policies

Currently, there is no way to do this.

Hybrid Approach for B2C to EEID

There is a repo. for this, as well as a more detailed one.

The repo. describes a method that I refer to as the hybrid approach.

I have posted several articles on this topic.

Essentially, you replace the B2C API with a REST API that points to EEID.

This way, you can use custom policies, but the data lives in EEID.

Note: This approach does not migrate social users since they will be automatically added the first time the user logs in on EEID.

Note: The user must have an email identity, as EEID does not currently support usernames.

Note: It also doesn’t cater for user attributes or passwords being updated after the migration.

There are two scenarios for migration.

Just migrate the password

If the user has already been created in EEID, then only the password needs to be migrated.

The seamless migration looks like:

1. Add an extension attribute to user accounts in B2C which flags their migration status
2. When a customer successfully signs in, read the B2C user account corresponding to the email address entered
3. If a customer’s account is already flagged as migrated, continue
4. If the user’s account is not flagged as already migrated, use the hybrid approach to write the password to the user’s EEID account and change the extension attribute in B2C to mark the account as migrated

At some point, when enough users’ passwords have been migrated, you switch the app. to point to EEID. Any users who have not logged in (and hence have not been migrated) must perform SSPR.

This is the approach followed in this repo.

Migrate the user details and password

The B2C custom policy authenticates the user and then creates their account in EEID. You have the password from the login, so that it can be migrated.

The seamless migration looks like:

1. Add an extension attribute to user accounts in B2C which flags their migration status
2. When a customer successfully signs in, read the B2C user account corresponding to the email address entered
3. If a customer’s account is already flagged as migrated, continue
4. If the user’s account is not flagged as already migrated, use the hybrid approach to write the user details (i.e. create the user) and password to EEID and change the extension attribute in B2C to mark the account as migrated

At some point, when enough users have been migrated, you switch the app. to point to EEID. Any users who have not logged in (and hence have not been migrated) will have to be manually migrated and must perform SSPR.

Details

What these approaches do is “silently” migrate the users to EEID so that when the company finally moves to EEID, most users and their valid passwords are present.

Part 1 of this flow deals with migrating both the user details and password.

As usual, the code for this approach is in the gist. The function code can be found here.

I used the function code I developed for the hybrid flow to perform user CRUD on EEID.

We have a user in B2C.

The migration flag in B2C is set to true.

 "extension_51...4e_requiresMigration": true,

The user is not in EEID.

We log into B2C, using the custom policy in the gist above.

We pass the SMS challenge and get the JWT back.

Now, when we look at the users in EEID:

we see that the user has been migrated.

Now we log in to EEID using the same password we used for B2C.

and enter the password.

Stay signed in.

and we get the JWT back:

{
  ...
  "iss": "https://7f...bb.ciamlogin.com/...",
  ...
  "ver": "2.0",
  "Mail": "migrateuser@company.co.nz"
}

Note that the “iss” is “ciamlogin”, proving that this is an EEID account.

The migration flag in B2C is now set to false:

 "extension_51...4e_requiresMigration": false,

When the app. is switched to EEID, the user can log in as usual. The only difference is the UI of the screens.

All good!

Some notes on migrating from Azure AD B2C to Entra External ID (EEID) (Part 1) was originally published in The new control plane on Medium, where people are continuing the conversation by highlighting and responding to this story.