You’re midway through the integration of a recent acquisition. Your team knows which apps are being brought over. They have even worked out how the data should be migrated over as well.
What about the users?
Sounds simple, but who’s responsible for them? Is it the app teams because they are closely associated with the apps being migrated. Is it the data teams because they reside in any number of databases? Is it HR because they are employees? Is it sales because they are customers?
This is the realm of identity access management (IAM). The glue that binds everything together. It is also the one piece that you cannot just “lift and shift” from the one organization.
The rest of the article will serve as a crash course digging into what is IAM, how it impacts the post-acquisition integration phase, and what you can do to minimize the risks involved with the impact.
What is IAM?
Identity access management is the catch-all for the users of a system and how they access the system. This includes things like user creation and deletion as well as granting and revoking permissions. Applications may also need to be managed with specific permissions.
If this sounds like a database, you are right. Of course, if you don’t have an account yet, then one needs to be created. That also falls under the realm of IAM where the new user is created (either you on the login page or inside the company as a part of the new customer on-boarding process, verified (the click a link sent from your email or the code sent to your phone), and linked (additional information with the company is provided to you to enter in to ensure you are setup correctly).
There is one more piece that comes into play and is more in the moment: session management
Session management is the part where you are presented with a login page, enter your username and password, and then are either allowed access to the app or not. When you are allowed access, then you are given a session token.
This session token is stored in your web browser, and inspected with each request the browser makes with the app. This inspection will be done any number of times whether through an intermediate gateway or at the app itself. Depending upon the user’s session and the policies for the application (or even a specific piece of the application), additional authentication checks may be made such as the biometric or multi-factor authentication for accessing sensitive data.
One other part that the session token plays is that it may contain additional details about the authenticated user such as a unique identifier so the underlying apps know what data to pull for the user, or which screens the user would have access to (think admin mode or per-department such as sales vs marketing).
As you can see there is a lot that goes into it. Even more-so when you consider a user can be an employee and entered into one database (usually Microsoft Active Directory) a customer and entered into a separate database (Okta for example), and sometimes both. If we only care about the users, then treating it as data and calling it a day would be okay.
Yet it is the session management piece that acts as the glue, and this is the part that provides most of the headaches in the integration phase.
How IAM impacts the integration phase?
In short, there are two things that need to be dealt with:
- Migrating and synchronizing the users (this is the obvious one that everyone knows about)
- Grafting the applications being conveyed
For the first point, there are a few questions that need to be addressed by the integration team and will dictate how much and the manner of the users being migrated. This would include factors such as:
- Where are the users from the authentication database perspective and how are they linked to the apps being conveyed?
- How are the apps being conveyed? All at once, or in batches?
- Are there common databases that the users will be added to? Will there be additional processing required if the common database already exists on the acquirer’s side?
- How will the cutover of the apps happen between the acquired company and the acquirer? If the app will be running concurrently for a time, will there be a synchronization process in place to ensure user changes in the old system propagate to the new?
- What does an administrative interfaces look like and will they require modifications to support the new business?
- Is there data that currently has no support in your organization that you would need to account for (international phone numbers for domestic only companies, GDPR for entering into Europe, etc.)?
- Are there any special events or high load times that need to be accounted for such as US open enrollment for benefits or end of year financial calculations?
These may seem simple or have already been accounted for, but even for my previous clients that have been operating for years, the last question was always forgotten because it was too obvious.
The user migration and the app linking will also factor in when it comes to the on-boarding and migration process. It may just be as simple as migrating the users over and calling it a day. But, there will be some data that is missing or will need to be changed (passwords being the most obvious). Another question is what will their experience look like post migration. Will they need to recreate their account in your system first, will a one-off program run that ensures the appropriate data gets linked in all associated databases, will an email go out to the user announcing the new system and how they should log in. Most importantly, can your system handle load spike for this one-off or annual event?
Looking at the second point, it should be raising a few eyebrows. Yes, I do mean grafting because each company has their own session management solution. Even if they share a common vendor as an identity provider. This is an area that is very much customized to your processes and policies. It is also the area that will have the greatest risk.
First is the question of how we obtain session. There will be a login page, but where is it hosted and how does it interact with the Identity Provider to authenticate the user and create the session? If it is included with the identity provider, and it is separate from what you use in house, then there will definitely be some custom development required. If everyone utilizes an open standard such as OAuth, then some of the rework could be minimized. In addition to the login page is if there is the concept of self-registration, how is that done with both organizations?
Next comes the policy enforcement points. Is this done inside the application, or with a 3rd party API/Web gateway? Is this something that was created in-house using a library such as Java’s LittleProxy. Do any of these read, decrypt, or modify any headers or session tokens to work with underlying applications?
Lastly what application mints and verifies the session? Is this a third-party provider such as Okta and Azure AD or was this built in house? If the latter, then you may have a little more flexibility. Regardless, while interoperability may be possible, there will be some quirks to that need to be kept in mind and planned around. Also, depending on the who mints the session will also dictate what is included with the session token such as unique identifiers that are consumed by the underlying applications to retrieve the app specific user data.
Needless to say, there are a considerable number of things involved that need to be coordinated. And none of this touches on how policies are enforced such as session lifetime, invalidation, or compliance.
What to watch out for to minimize your risk
This is the section you have all been waiting for. What can you do to minimize your risk and ensure everyone is on the same page?
The questions I ask above will be a good starting point. In addition to them:
- Does everyone know how the end user will interact with your company apps and the apps being conveyed? (the user journey)
- Have the critical dates been identified?
- Will the administrative apps need to be modified, and if so, how?
- What does the transition strategy look like?
Ensure everyone, especially from the company being acquired, understands all of the user journeys
This should include the employees as well as all possible users. Admins, customers, customer admins, etc. For each of these personas, ensure you have accounted for:
- How a new user is created
- How the user logs in for the first time
- How they log in from a trusted location/device
- What happens if they leave?
- What happens if the account is compromised
These will uncover a lot of the gaps that I have identified above in a holistic fashion. Additionally, it will provide the transition team guidance on how to notify the users on what to expect as well as plan out the next steps to correspond with your critical dates.
Also, and more importantly, this will identify the body of work that will need to be completed between the common infrastructure apps of user creation and login, app access, and the authorization policies to ensure everything continues to work.
Ensure everyone knows what to expect for critical dates
This is restating the the point I outlined above, but cannot be underestimated. Your schedule will either be driven towards it, or you will realize things will break when you hit them inadvertently. Is it quarterly or annually? Which systems are impacted, and who out of the user population will be impacted? Is the entirety of your IT environment ready (such as mail servers if you are sending out user notifications)?
Will the administrative apps need to be modified
In this case, this will be the primary administrative applications used to handle the user and app creation/deletion as well as the authorization pieces. Will new groups/entitlements/permissions be required, will you need to add support for things beyond multi-factored authentication such as passkeys? Will there need to be a user/permission delegation feature added? Will this be global or per-app?
Neglecting this will result in a system that you cannot modify after the cut-over and will be outside of your control until it is done.
What does the transition and on-boarding strategy look like
From a user experience standpoint, hard cut-overs are painful. Additionally, it takes a lot of time, energy, and effort to get everything in place with no way to test things out until the cut-over event. This is why I wrote a series of posts a long time ago on migration strategies for legacy systems. Yes it also applies to this use case too.
Drastic cut-over changes are highly risky and unless they can be tested in multiple environments or with duplicate hardware, you won’t know until you do it. However, there are things that can be put into place where you could transition web traffic slowly between the systems, but this does require a lot of care and planning (meaning cost to the financial folks reading). By extension, buying a second mainframe just for a cut-over exercise is a bit much.
However, there are other things that can be done for the slow transition. Migrate users in batches, or group them based on a certain criteria. Redirect web traffic to the old and new systems.
Depending on the approach taken will dictate how the users and apps are migrated, and more importantly, whether the data will be synchronized back to the old organization. This will include things like user activation emails that will go out once a the account has been created/migrated over or password reset links to force an update.
Lastly, some other questions to address is how to handle inactive accounts (created, but not used since the initial setup), disabled or archived accounts (migrated to an off-line state where the company isn’t paying for them or no longer usable), or duplicate accounts (a user existing in both the acquired and acquiring company). This may seem straight forward, but is also dependent upon the business cases.
Conclusion
The identity space is the glue between the applications and the data and have multiple touch-points that will need attention and care. Far beyond looking at just the apps or the data. It is also the one place everyone will blame if/when things go wrong even though it is usually just the messenger. Ensuring everyone is on the same page with the user journeys will help with about 70% of the issues you could run into, but remembering that you cannot “lift and shift” applications into your environment. Instead, thinking of them as a graft into your environment to ensure they are compliant with your policies and controls as well as ensure a consistent user experience going forward will go a long way towards reducing the tech debt post-acquisition.
If you don’t address these issues or questions that I raise, then I would expect things to break, first within 6 months post-acquisition as you realize that the session data from your environment is incompatible with the apps you just conveyed. Second when someone notices that the login experience will be different, and ask for you to bring over the original login page to realize that it will be impossible. Third will be once the cut-over is complete and the emails going out to your new customers just brought down production.
If any of these things worry you, or you realize that your team may not know what to ask, then let me know and we can discuss it more.