Phased migration of Apps to B2C
Phased Migration of Apps from Legacy IDP to Azure AD B2C
Many customers have a setup like the following
They would like to progressively migrate these apps to B2C.
The users need to be using the same username/password and preferably single sign on also works across applications.
Every customer that we have come across so far have unique needs so a common solution is hard to find. However there are 2 solution templates applicable across customers:
There are 2 steps in this solution. In the first step the Identity data is migrated to B2C. Legacy authentication system uses B2C as the idp. The protocol it talks to the client applications is unchanged. So no changes in the application. In the second step applications are moved to talk to B2C directly in a phased manner.
Legacy authentication system and B2C directories are kept in sync by a sync process. Single sign on will not work in this case but the username/password is the same across applications.
In both these scenarios passwords need handling. The details are in the following sections.
The advantages of solution 1 are:
Identity data is protected by Microsoft. Although the authentication end points for non-migrated applications are not protected by Microsoft, it still offers a large amount of protection.
Single sign on across migrated and non-migrated apps can be made to work on certain scenarios(like ADFS). Details below.
Less maintenance than running a sync engine.
The cons of solution 1 is it requires a higher up front cost.
Solution 1 is recommended in the following cases:
The authentication system has an easily pluggable IdP.(eg ADFS or custom authentication end point)
The migration of all the apps is a long process thus justifying the initial investment in modifying the legacy authentication system.
The advantages of solution 2 are:
Assuming sync is provided as a service by a 3rd party vendor, the cost is only to migrate the app which is lower than re-wiring legacy authentication systems. If the total migration time is short( a matter of months) the total cost could be significantly lower than solution 1.
Cons
If B2C is being adapted for security/compliance reasons, until the last app is migrated the benefits cannot be realized.
There is an ongoing maintenance cost in running a sync engine.
Single sign on across migrated and non-migrated apps won’t work.
Solution 2 is recommended when:
Solution 1 is not technically feasible.
Cost of modifying the legacy authn system does not fit the budget.
Migration life cycle is short.
Solution 1 details:
2 typical setups are covered here. However customers have many different setups and solution needs to be modified appropriately.
Setup 1: Custom API based authentication system.
Setup 2: An authentication system with a pluggable openid provider as IDP. Eg – ADFS
Setup 1: Custom API based authentication system.
Step 1: The identity data is migrated to B2C.
Step 2: Passwords are migrated to B2C as users login/reset.
Step 3: Legacy authentication system authenticates using either EVO ropc/graph or B2C ropc when it is available. If users login whose passwords are not migrated the legacy authentication system validates those users and stores the passwords in B2C.
Step 4: Apps are migrated to B2C.
Setup 2: An authentication system with a pluggable openid provider as IDP. Eg – ADFS
Once the passwords are migrated the legacy authentication system can redirect to B2C for authentication. SSO will work across applications.
Password migration strategy depends on the legacy idp. If the IdP allows access to hashed passwords and the hash is known, there are known solutions for it.
If the legacy IdP does not meet those criteria but has an API to validate passwords, a REST API can be put above it and consumed by B2C for password migration.
Solution 2 Details – Sync
Identity data is migrated to B2C. Passwords are migrated using one of the known techniques.
A scheduled sync job moves the identity data updates from legacy system to B2C.
Updates happening on the B2C side are dual written to B2C and legacy system. There is no sync from B2C to legacy. If write calls to legacy system fails B2C database is not updates.
This minimizes the changes to legacy system. Customization is only done on B2C side.
