Top IDM Challenges in Mergers and Acquisitions
When companies merge, they face a distinct set of identity management challenges. This is due to each former company having its own identity management system complete with a distinct set of users, applications and directories. After the merger, they want to combine into a single identity community.
At AssureBridge, we have worked with many clients undergoing mergers and have found similar Identity Management challenges.
On the surface, this seems straightforward. The pre-merger state is as follows:
Figure 1: Pre-merger IDM
Each company has distinct applications and one (or more) directories containing the company’s employees (and maybe customers).
Their end state is to combine like this:
Figure 2: End state IDM Consolidation
All the applications point to a single merged directory that contains all the users.
To merge the identities, just move the users into a single directory and repoint the applications to the new, combined directory. Simple enough, right?
If the target acquisition is much smaller than the acquiring company, it may be this simple. Many if not most of the target company’s applications can be retired and the users can be re-input into the main directory. But when both organizations are relatively large, this is usually completely impractical.
The challenges we have seen include:
- Heterogeneous identity sources. Each merging organization has at least one entrenched directory and each directory is organized uniquely. The directory schema and attributes are different and the various applications depend on those differences.
- Usage of the directories by applications has grown organically over time. It is not clear exactly what information is being used by each application and what would be the consequence of restructuring the directories.
- Customers are often in separate stores from employees, which may not be directories at all but databases.
- All the organizations have mission critical work and cannot afford the disruption of a massive Identity Management overhaul
- For international mergers, regulations like GDPR, do not allow, personal employee/customer information to be moved offshore.
For these reasons, most of our clients do not want to rush into an IDM consolidation project. Unfortunately, the business needs of the merger demand that at least some application and data sharing take place between the new divisions. This is a risky time, where users often get double-entered into multiple directories as a stop-gap. Since a directory merge project can take years to implement, the existing directories get polluted with redundant information making them very difficult to clean up in the future.
So, starting a large migration effort is too costly and time consuming while doing nothing digs the hole deeper. Fortunately, there is a middle ground that allows gradual migration without disruption. Our clients have successfully used two approaches (alone or in combination) to keep the business running without causing the identity ecosystem to become corrupt, redundant and unwieldy.
User Mart Strategy
The User Mart strategy places a single, read-only directory in front of the existing divisions’ directories (and/or customer database). This mart contains the bare minimum information to operate the applications and data access but not excessive personal information (to avoid running afoul of privacy rules). User information is still kept in the local division’s directory but it is synced in near-time to the mart.
Figure 3: User Mart Migration Strategy
Initially, nothing changes, users still log in and access applications like they are used to. However, when an applications become shared across divisions, it is re-pointed to the user mart. The mart contains the needed info for the shared applications to run, however, it does not contain personal information or passwords. When a user logs in via the user-mart-attached application, the mart transparently passes the login request back to the original directory via Pass-through Authentication (PTA). This allows the shared applications to be re-pointed one at a time. There is only one system of record for any given user so the data does not become redundant or corrupted. Eventually, all the applications may become shared, the legacy directories retired, and the user mart (or other directory) re-designated as the single, corporate-wide directory, but there is no rush.
It’s essential that the user mart be an enterprise-class directory since the shared applications will depend on it. It needs robust high availability and backup and the synchronization must be rock solid. The user schema should be the ideal target state. The synchronization converts from the legacy schemas to the target schema in near time. This way, nothing needs to change on the original directories, but there is steady progress to the combined, ideal schema.
Single Sign-on Strategy
When the shared applications already use or can easily use single sign-on (SSO), another approach is to use SSO routing to direct user sign-on to the proper directory. Shared applications may already be enabled for SSO (e.g. via ADFS). In this case, they are re-pointed to an SSO routing identity gateway which determines who the user is, and then routes the sign-on request to the appropriate, back-end identity server.
Figure 4: SSO Gateway
In this scenario, each backend directory still manages its own set of users, there is no replication of data, and data stays local to its geography. The SSO response collects the needed data (e.g. email address, country of origin, title, etc.) from the appropriate server and packages it as part of the SSO Assertion. This approach maintains a very strict “need to know” policy, giving each application only the minimum information it needs to operate. It also has the advantage of supporting additional identity sources (e.g. customer Identity Providers). As in the first solution, the backend directories can still be consolidated over time, but there is no rush.
One of the challenges of this approach is identity routing. When a user attempts to log in, the gateway must determine where the user’s identity is stored and route the request appropriately. Some strategies our customers employ include:
- Drop down lists (ask the employee what division they belongs to)
- Tracking cookies to remember user’s home division
- Separate login URLs for each division
- Using the login name to determine division (if obvious from the user’s email)
Our customers often combine both the user mart and SSO strategies as some applications require single sign-on and some do not (or cannot).
By using migration rather than the “big-bang” cutover, merged companies can practically move from a distributed set of identity management systems to a single consolidated system at their own pace without business disruption.