IAM Transition Strategies

Introduction

One of the common challenges organizations face when it comes to Identity and Access Management (IAM) is transitioning between systems. Credentials are a cause for great concern in this process because most systems do not make credentials visible in any form, let alone clear text, and there are also differences in password policies between the different systems.

Transitioning identities between systems may be required in the following situations:

1. Consolidate users from multiple identity silos into one system for easier management
2. Identity housekeeping to reorganize, restructure, and simplify directories
3. When organizations merge or are acquired, they may consolidate and centralize user management
4. Split users out of a directory if a branch organization is sold or spun-out into a new venture
5. Geo-political, data protection, compliance, and regulatory reasons to separate or move identity data
6. Cleaning up directories is good practice to remove garbage accounts and associated security risks

In order to better understand the different approaches to transitioning, and their pros and cons, we need to first understand the different identity management solution patterns that exist. This will help us to choose the right target model and transition strategy

There are two common approaches taken for IAM transitions:

1. Big bang adoption
2. Parallel adoption

More often than not, you would be required to employ a mix of the above strategies to transition all your applications to the target IAM system.

Big Bang Adoption

Big bang adoption methods involve transitioning all the identities from the source system to the target system simultaneously, and optionally getting rid of the source system if it is not required any more.

Advantages:

• Faster and easier to implement
• Avoids problems of running multiple systems in parallel
• Could be the least expensive method because once we completely cutover to the target system, the old system can be decommissioned

Disadvantage:

• In case a problem is identified after the cutover, there is no system to fallback on

If the target system and source system are not compatible to be run in parallel, then big bang adoption may be the only choice we are left with. For example, if in the new system a non-null database column is added without a default value, that would mean that the new schema is not backward compatible with the old system. Therefore both the systems cannot run in parallel by sharing the same database.

There are two big bang adoption methods - data integration and data migration.

Data Integration

One of the very basic methods of transitioning IAM from the source system to the target system is data integration. Checkout the discussion on “data integration” approaches in my article on “Identity Management Solution Patterns” for a discussion on how data integration could be achieved between systems. If the source system doesn’t need direct access to the data store and can completely delegate IAM to the target system, we can completely disconnect the integration in the source system. However, there are some of challenges in this approach as discussed in this article and these are:

• Incompatible data store types
• Incompatible secret hashing/encryption functions
• Effect of caching strategies employed by the applications or services
• Restrictive firewall policies
• If your internal users are accessing external applications/services that are outside your corporate network
• If external users are accessing your internal applications/services and their data store is in their network

In addition to the above, following are some additional challenges that you could come across especially when you want to transition your IAM:

• Multiple applications or services with each having its own data store, all of them have to be connected to the target system as data stores. For this purpose, most IAM vendors support multiple data store integrations.
• If the source systems were being managed like identity silos that duplicated user accounts across each of the systems, then when they are transitioned to the target system, you may need to consider a local account linking or local account merging process, in order to identify the set of accounts in the target system that belong to the same identity.

The goals of local account linking or local account merging are:

1. Consolidate the accounts to have one primary unique and immutable identifier for an account. The account may still have multiple login login names if necessary.
2. Consolidate the accounts to have one credential value per credential type.
3. Claims, groups, and relationships are consolidated for the identity. Conflicting values have to be resolved during the process.
4. Entitlements are consolidated for the identity. Conflicting entitlements have to be resolved during the process.

Consolidation and conflict resolution may be configured to happen automatically or manually. Manual methods may involve self-service resolution or assigning a task to an administrator to resolve it.

Data Migration

In case sharing or moving of data stores does not work, the next best big bang adoption method to consider is data migration of the existing accounts and entitlements to the target system. Data migration can happen at two levels - at the data store level and the application level.

In most types of data stores there will be some kind of bulk import/export mechanism available. For example, in LDAPs you can export/import to/from LDIF files. In JDBC data stores you can export/import to/from SQL Dumps. In applications, export/import would be supported by manual methods via the UI or programmatically via an API, or both. Such export/import options tend to use data formats such as CSV, XML, etc. If the application supports standard APIs such as SCIM, that will be an advantage because then you will be able to reuse the SCIM client that you write to transition from more than just one source system that supports SCIM. In some cases you may have to do adopt a hybrid approach to handle export and import. For example, the source system may support a bulk export using CSV, but the target system may not support a bulk import using CSV. However it may support a bulk import using SCIM. In that case, you need to be able to feed the CSV as input to your SCIM client and bulk provision the accounts to the target system.

The main challenge you will face in the data migration approach would be migrating passwords, any kind of secrets that are hashed or any sensitive information that is encrypted. Most LDAP based implementations will not disclose passwords even in hashed form. In JDBC data stores at best you may be able to extract the hashed passwords. For hashed secrets, if you are able to get hashed values and the target system supports the exact same hashing algorithm, you will be able to directly import that data to the target system. Otherwise, you may end up customizing the data store plugin to support the hashing algorithm.

Similarly in the case of encrypted data, if you are able to get the encrypted data and the target system supports the exact same encryption algorithm, you will be able to import that data to the target system directly. Otherwise, either you have to run the encrypted data through a decryption program before you import the plain text data into the target system, or customize the data store plugin to support the same encryption algorithm as the source system.

Forced Password Resets

Forced password resets could compliment the big bang adoption methods we’ve discussed so far, in order to help in situations where big bang password migrations are impossible. For the methods where the account provisioning goes through the target system, a forced password reset flow can be initiated along with the provisioning request. And for the methods where the accounts were directly provisioned to the data store without going through the target system a forced password reset flow can be initiated as it would be done for an existing user. This can be initiated in bulk for many accounts in parallel.

Forced password resets generally have two kinds of user experiences:

1. Lock the user’s account and send an email with a password reset link.
2. Lock the user’s account and force the user to update his/her password every time (s)he tries to login through the target system. You can either use a one time confirmation link sent to the user’s verified email address, or use a OTP that is sent to the user’s verified email address or mobile number.

Parallel Adoption

Parallel adoption methods involve using the source and target systems simultaneously until all the identities are transitioned to the target system, and optionally getting rid of the source system if it is not required any more once all identities are transitioned. Advantages and disadvantages of parallel adoption will be the exact opposite of big bang adoption discussed earlier.

While parallel adoption methods can be used to migrate complete user profiles, they are particularly useful in migrating passwords and secrets in conjunction with big bang adoption methods for the remaining user profile, in one or more of the following scenarios:

• If the source system passwords or secrets cannot be migrated by following the approaches suggested in big bang adoption.
• There is no verified address (e.g. email address or mobile number) attached to the account to perform a forced password reset.
• The target system does not have a forced password reset capability.
• To provide a seamless user experience by allowing the user to continue using his/her previous password, if and only if the previous password passes the target system’s password policy requirements.
• To provide a graceful user experience by allowing the user to continue authenticating with his/her previous password until a predefined grace time limit and eventually force him/her to reset his/her password. During this grace period you can notify the user periodically via an email or using a UI message.

There are two types of parallel adoption methods - password (re-)set on login and identity federation with JIT provisioning.

Password (Re-)Set On Login

Customize the login flow to incorporate a password (re-)set option on successful login with existing credentials. The advantage of doing the (re-)set during the login flow is that the target system has access to the user’s existing password in plain text. And if this password passes the target system’s password policy requirements, we have the option of setting the existing password from the source system as the password in the target system, for a seamless user experience during parallel adoption. If a grace period is to be given for password reset, include the password reset option on every successful login, until the user decides to reset his/her password. If a grace period is not required, make the password reset a mandatory part of the flow instead of making it an option.

We assume that the source system’s passwords are somehow made available for authentication to the target system. For example, big bang approaches such as sharing could be used for this.

Following are the high level steps in this flow:

1. Once the user has successfully logged in using his/her existing password, provide the user with a choice of either logging into the application or service and resetting his/her password. If a grace period to reset the password is not required, do not give the option to continue logging into the application or service.
2. If the user chooses to reset the password, capture the new plain text password the user enters, and store it according to the password storage policies in the target system.
3. Maintain a lookup table to track user accounts that have and have not reset their passwords after the transition process was commissioned. Prompt for password reset only for users who have not reset their password based on the lookup table.
4. Whenever a password reset occurs, either via the “force password reset on next successful login”, or the usual “self-service password reset” or “forgot password”, update the user account’s entry in the lookup table to say password was reset.
5. Once all user accounts have been successfully transitioned according to the lookup table or you decide to terminate the transition process, decommission the transition process.

Identity Federation with JIT Provisioning

Identity federation with JIT provisioning can also be used as a transition strategy for IAM. Read my article on the topic to learn more about this technique. If passwords are provisioned in the target system, the federated identity provider can be disconnected from the ecosystem, once all identities have been migrated to the target system.

Decommissioning the Source System:

1. You can decide to decommission the old system after transitioning all the user accounts to the target system. However, this may be time consuming or may never happen if you are looking at Customer IAM (CIAM).
2. You can fix a deadline and notify all users about the deadline. Users can be notified via email or UI messages in the application or service.
3. Decide on a percentage of the total users and once that number is achieved completely cutover to the new system and force the remaining users follow the transition process.

Other challenges in IAM transitions:

1. Users may ignore the password reset links sent to their email addresses and continue using the current system.
2. Users may navigate away from password reset pages and come back later to the system to login with their old passwords.
3. Although not directly related to the topic of IAM transition, there may be additional requirements in the target system that may have to be fulfilled as part of the transition process (for example, claim verification). You could perform a claim verification as part of the transition process in order to minimize disruption to the user experience.

Summary

In this article we took a look at some popular IAM transition strategies, that may help you transition your identities from a source system to a target system with minimal disruption to users.

WSO2 Identity Server is an open source IAM product, distributed under the Apache 2.0 license. This product possesses a powerful identity integration and identity federation framework, giving it the ability to support all IAM transition strategies that we explored in this article.

Additional Reading

Identity Management Solution Patterns

What is Federated Identity Management?