Auth at One Place (AOP)

Every organization will have different kinds of applications. Each application will have different types of users with different kinds of roles. Users can belong to organizations, partner organizations, and external entities. We need to authenticate the user based on the type and provide the corresponding permission on each application. Organizations will face many issues while upgrading their authentication on different applications due to different kinds of identity mechanisms on different mediums. We can solve this issue by Unified identify provider.

A unified identity provider (IdP) is a single point of authentication for users to access multiple applications and services. This can help improve security and efficiency by reducing the number of passwords users need to remember and manage. Unified IdPs can also help to improve compliance by providing a single place to manage user access rights.

A unified identity provider can be achieved by migrating the different kinds of Identity Providers into one. Identity provider migration is the process of moving users from one identity provider (IdP) to another. This can be done for a variety of reasons, such as:

  • To improve security
  • To reduce costs
  • To improve user experience
  • To comply with regulations

The process of migrating identity providers can be complex and time-consuming. It is important to carefully plan the migration and to have a clear understanding of the risks involved. Some of the key steps involved in identity provider migration include:

  • Evaluating the current IdP
  • Selecting a new IdP
  • Testing the new IdP
  • Migrating users to the new IdP
  • Decommissioning the old IdP

It is important to carefully evaluate the current IdP before selecting a new one. This includes considering factors such as security, cost, user experience, and compliance.

Once a new IdP has been selected, it is important to test it thoroughly to ensure it meets your needs. This includes testing user authentication, user provisioning, and user management.

Once the new IdP has been tested, it is time to migrate users. This can be done in several ways, such as:

  • Manually migrating users
  • Using a migration tool

Once users have been migrated, the old IdP can be decommissioned. This includes removing the IdP from all applications and systems.

Phase 1 - Duplicate User Information in AOP-IdP

AOP-IdP

Once the new IdP is ready, one of the client applications will start using the new IdP for login. The new AOP-IdP will check the user is available in the new system. Users will not be available, so the authentication will get validated by legacy IdP. Once it's validated by legacy IdP, AOP will store the username and password in the new system based on their configurations. So next login onwards, AOP will do the authentication and proceed further. Using this approach, active users will get migrated first on their first login. Based on their user count, it will require a week or month. After the timeline, users will be available in new and old IdP.           

Phase 2 - Password Sync

AOP-IdP

In Phase 1, we migrated only one client application into our new AOP. The rest of the client applications can point to the new AOP for their authentication. It will be a time-consuming process. Within that period, the user can change the password via both IdP. So, the password needs to be synced in both places. We need to implement the retry mechanism in case any failure occurs on password sync. Users can log in with their new password in both IdP after they have reset their passwords.         

Phase 3 - Inactive users' migration

AOP-IdP

Inactive users' data will be available only in the old IdP alone because they didn't log in a single time after the release of the new AOP-IdP. We need to use the migration tool to copy the inactive users into the new IdP. Based on the business needs, we can select the list of information that will be required to copy into the new system. There are two ways on the inactive user's password.

  1. We can copy the existing password into the new one. But the migration tool needs to decrypt the password from the old one and encrypt it again in the new one based on the encryption mechanism followed in the AOP.
  2. We can skip the password while copying the user information. So inactive users need to rest their password while login into AOP.

Based on the business needs, we can select any one of the approaches.

Phase 4 - Decommissioning the old IdP

AOP-IdP

All users have been migrated into the new AOP, and all client applications also migrated into the new AOP-IdP. So, we can clear the user information in the legacy IdP and stop those services.

The next article will discuss merging the users from two organizations into our new AOP-IdP.       


Similar Articles