Company mergers and acquisitions are no longer a rare occurrence. They happen all the time. And with these mergers come a boatload of challenges for those tasked with rationalizing the identity & access management (IAM) environment. The immediate objective, is of course to allow users from either organization to access resources that are now shared across both merged entities. A simple enough objective that opens the door to a can of worms, or worse!
Challenge 1: Different Identity Formats
Company A uses employee IDs of type XYZ1234 to uniquely identify their users and associate their accesses in a majority of applications, especially their Active Directory. So, users in Company A typically login with this employee ID and password and get to whatever and wherever they need. Company B on the other hand, has people login with their email addresses, something like John.Doe@ABC.com. Irrespective of who wins the arm-wrestling challenge, significant changes are required to have applications work with either approach. How can you resolve this with limited time, limited budget and application owners who have their own prioritized timelines?
Challenge 2: Same User, Multiple Identities
Company A has been pretty good about AD domain consolidation. All their employees and contractors access the environment through accounts provisioned in a single AD domain. Not so Company B. They have a raft of AD domains created for different purposes and this has inherently muddied the water as they tried to go to a single sign on (SSO) solution. SSO providers like to have ground rules on how to identify where to go to validate a user’s identity. Given multiple choices a lot of custom code was built within their SSO solution to identify a user’s home domain and this is complex in itself. Now bring in Company A with their different identity rules and the complexity goes to a whole new level.
If one, or other, or both of the challenges sound familiar, you are not alone. Let me discuss one approach we at #pontisresearch used for an organization building an SSO portal. We started by consolidating all identities within the identity solution. This led to the unexpected discovery that some users had, based on matching attributes such as first and last names, last 4 of SSN, multiple identities, sprinkled across different AD domains. The obvious issue was which of these identities was the primary one the user would like to login with? The IAM team decided to allow users to pick at the time of first login. But, just in case the ID matching algorithm was inaccurate and had incorrectly linked identities we did not want to show the user the list of matched identities. Additional authentication was called for and additional controls were added around user ID selection.
Next came the issue of different profiles/user IDs for different applications. This problem was handled by prompting the user to select what they were looking to do, and then based on the application being accessed flipping the identity information provided in the token or header to match the target application’s expectations. This worked well for the majority of applications. For those that did not we found an alternative that the business found acceptable.
There’s a lot more I could add here, but that was not the purpose of this post. To summarize, when it comes to IAM, remember if an M&A leaves you feeling like you are being asked to match apples and oranges, with a bit of creativity and some planning you can avoid coming up with a lemon!