How your users access your apps and the apps being conveyed is where a large amount of “Synergy capture” happens. When done right, you will see significant cost savings and a better security posture. When done poorly, the integration work will be delayed substantially (think months at a minimum), be considerably more costly, and can leave you in a far riskier position. Just like everything else, there is no “one size” for everything, but it also means that you will need to think twice about “lifting and shifting” the apps over let alone the users.
There are two common patterns that have existed for years in the identity space. Depending on the patterns defined not just at the organization level, but the per-app level, will dictate your approach, and what work will be required.
We’ll start by looking at the two common user management patterns, what needs to be factored in during the migration including what things need to be accounted for if you must bridge between the patterns. Lastly, will be a few notes on some corner cases.
The focus is on traditional users; app integrations would follow a similar approach given the authentication and authorization pieces.
The Localized Pattern
In the old days (think of the original UNIX/VAX time-sharing systems), there was one system, one console, and if you were lucky, a modem so that you could connect to the computer from home. Your credentials were stored in one place on the computer, and the computer made the final decision on whether to let you in. Those early apps had a similar approach, but with a different purpose.
In those days, authorization and auditing were a small part of why the authentication piece existed. Instead, it was a mechanism to allow one person in at a time and let others know who was in there. If Alice tried to access the app and log in, the app would deny her access and tell her Bob was using it at the time.
These are very early and simple examples of the localized access. More recent examples would be the web apps that store the user data in its database. They are very quick and simple to build and manage. It is mostly self-contained from the users all the way up to the login experience.
The biggest drawback to this pattern is that users had to be managed from within the app. If this is the only app and the user base is small, then it isn’t an issue. It is once an organization and the number of apps in the ecosystem begin to grow that it becomes time-consuming. Doubly so when there is a surge in new users being on-boarded, off-boarded, or migrated elsewhere post-acquisition.
The Centralized Pattern
It is the drawback of the localized pattern above that has prompted the developers of the day to figure out how to provide a way to centralize user management. In the UNIX realm, this started off with a user file per host that would not only gate access to the system, but APIs were made available to leverage UNIX’s core user base. This became more complex as computers were networked together requiring not just users to be authenticated, but their computers too (the birth of LDAP and Active Directory). The internet age gave rise to other technologies such as the single sign-on concept and OAuth for user and app-based authentication/authorization. The developer no longer had to implement a login page, nor set up their own user management.
With this added complexity, you no longer needed to implement a user login/management interface for each app. You could create users, grant and revoke access to apps by adding roles/permissions in the central user database. You could centralize the authentication and authorization policies through common infrastructure providing a consistent look and feel for all users depending on their role (customer, employee, vendor, etc.).
One of drawbacks is that most off the shelf apps still needed to implement their own user management system to bootstrap into a new environment. Unless steps were taken to disable this configuration during the installation, it could provide a backdoor into your app (best case) or corporate network (worst case).
Another drawback, and this is specific to the post-acquisition integration phase, is that centralizing user management and authentication implies shared infrastructure that will need to be duplicated in the case of a “lift and shift” approach or replaced outright requiring modifications of the underlying applications in addition to migrating users.
We Already Know This. Tell Us Why We Should Care
While this seems obvious, the fact is that the patterns are reflective of the various apps and underlying systems and will differ from any enterprise mandate or best practice. However, for the tech being conveyed, they could still fall into one of the two above patterns depending on usage, maturity, or other historical reasons.
If you are conveying the users or the users and the apps, there are different approaches based on the above patterns. Additionally, if you are going from a localized pattern into a centralized pattern, then there will almost certainly be some additional development work required.
Another piece to keep in mind is the localization pattern tends to favor an all-encompassing solution where identity, authorization, and app data co-mingle. It can allow for things such as fine grain authorization based on app-based rules. However, when it comes time to migrate the users over, you will need to tease out the identity specific data from the app specific pieces. Especially when going into the centralized pattern approach.
One other item to note: even if an application is considered to fit a localized pattern, if it is dependent upon 3rd party technology for the authentication/authorization piece (such as leveraging Kong’s concept of a consumer or your web server’s authentication mechanism), then they must be treated as a centralized pattern because of the common infrastructure that may not be conveyed along with the underlying application.
Migration Approaches
Approach 1: Localized to Localized
This is the simplest and best approach that you could hope for. It is also one of the few places where lifting and shifting the app and data to their new home is doable. This doesn’t mean you shouldn’t be conducting your normal tech diligence around the app ensuring proper maintenance and compliance.
If this app will be used with your pre-existing user base, then outside of the rebranding work, setting up a data migration/synchronization program may be the only conveying work required at a high-level. This is the part where the work will be dictated more by the ultimate goals of the acquisition.
Of course, if only the user data is being conveyed to one of your apps, then the same data migration/sync work will be required.
The thing to be careful of is if there is any common infrastructure that is used to support the application from an authentication, authorization, or API routing perspective. Even if they will be coming along with the app, these pieces (which usually have tight coupling with the underlying app), will need to be modified or replaced prompting some code rework.
Approach 2: Centralized to Centralized
In this approach, the apps and data being conveyed into your ecosystem come from a centralized user database, and both have centralized tooling in place. Depending on the maturity of both ecosystems, the migration could be simple where you are migrating users into your identity provider and changing the SAML/OAuth configurations to match the new ecosystem.
The app changes should be minimal in this case as you are leveraging the pre-existing infrastructure. Granted, migrating between different identity providers will have its own integration challenges. Even if both organizations have the same vendor will have differences based on the different user journeys or data rules.
Another consideration is the business edge cases that would be more common in the centralized pattern. Support for things like federation between customer institutions and vendors, international customers, or even managing a public facing developer API into the custom apps.
Approach 3: Localized to Centralized
Just like the first migration approach of going from a localized pattern to a localized pattern, the app being conveyed is self-contained. The ultimate goal is to extract just enough of the user data to utilize the centralized pattern. Additionally, since authentication and authorization will be performed by common infrastructure, these components can be safely removed from the app being conveyed.
Apps and users being conveyed that fall into this pattern migration will need proper analysis and design for the transition.
Before breaking down the work, looking at all of the user paths (login, initial on-boarding, password reset, privilege escalation, and revocation) will go a long way towards understanding which user attributes are identity specific fit for migrating into the centralized identity provider and app specific. It will also highlight what user on-boarding will look like in the new world with the centralized identity provider. Lastly, these paths will help you identify which user specific data is app related or user related.
More importantly, this work will identify which parts of the user authentication, authorization, and management will need to be replaced, or removed.
Approach 4: Centralized to Localized
The final approach will be very similar to the previous approach in both risk and complexity. This approach will also be more common for apps being carved out as a part of a divestiture where the new entity may not even have the centralized infrastructure in place.
You will still need to perform the analysis and design for each of the user journeys, but then look at what is being done today with the centralized pattern. Assuming that ecosystem is going away, how much of what is being done do you really need, and then with an eye towards the future, what makes the most sense for this app and the longer-term goals for this divestiture.
These initial questions should provide enough insight to highlight what functionality needs to be replaced and how to handle the user synchronization until it is time to pull the proverbial plug.
Multiple Providers
There will be scenarios where an application may need to work with multiple providers. The approaches and scenarios outlined here assume a single identity provider in the mix. For multiple providers, then you could treat each integration as a separate approach for one of the two patterns, but paying especially close attention to the user journey piece as it applies to each provider use case. In some cases, the app may act as its own service provider when it comes to managing session based on the multiple identity providers (borrowing from the OAuth2 world).
Bridging Multiple Systems
One last consideration touches the migrating to and from the centralized pattern more than the localized pattern, and it touches on the same users existing in multiple systems. In the localized pattern the same person is treated as two unique users because each system has no concept of anything else outside of their ecosystem. The entire point of the centralized pattern is to bridge these systems. Sometimes it is a username, email address, or a unique number. The point is having a unique way of identifying the user, and binding not just the identity data, but their own app specific data as well.
When it comes to combining into the centralized identity provider, the migration process will require a few checks:
- Identify a unique human readable identifier field
- Identify a unique key (number) that can bind the user to their app data in an easy to search fashion
- Determine how to resolve conflicts in this unique human readable identifier
- Determine other attributes that can be used to uniquely identify the person and attempt to resolve duplicate entries (in case the user has an account with both companies pre-acquisition)
Concluding Remarks
While the concepts of user management and origins can seem very trivial on a large scale, only when you start integrating the custom apps or appliances over do you begin to see the impact post-acquisition. Hopefully this will give you a few things to consider as you start looking at the apps and wondering how to convey them.
If you or your team are struggling with how to move forward on conveying these new apps post-acquisition, then let me know.