How to Overcome the Challenges of Legacy Identity Migration

Written by Eric Olden, CEO of Strata Identity.

Originally published on Forbes.

Identity has always been the cornerstone for controlling access to the apps and data employees and customers need. And with the advent of cloud computing, managing identity now requires organizations to reconcile their legacy on-premises systems with modern cloud identity providers (IDPs)—all of which use different protocols and are incompatible with each other.

Ideally, enterprises would move to cloud-based IDPs such as Okta, AWS or Azure as efficiently as possible; they enable superior security and support important features such as passwordless access and multifactor authentication (MFA). In a world where a ransomware attack occurs every 11 seconds, MFA, once a nice-to-have capability, is quickly moving into the must-have category since it blocks 99.9% of automated cyberattacks.

Legacy IDPs and the apps they secure can’t support these essential security features, which is a roadblock to implementing modern authentication mechanisms.

The Complexity Challenge

Unfortunately, moving apps to a modern IDP is both time-consuming and expensive. Generally speaking, enterprise identity systems are hard-coded in the application itself, which has traditionally meant that apps must be rewritten to support a new, cloud-based identity system. Doing so consumes significant developer hours (something that is always in short supply) and can create other problems. For example, applications that have been modified may not be able to accept upgrades.

Also, some applications may need to remain on legacy identity systems while others move to the cloud. This means companies must support hybrid and coexistence scenarios (i.e., on-premises IDPs plus one or more modern cloud IDPs), none of which will be able to communicate with one another without extensive recoding.

Multi-Cloud, Multi-Vendor

Identity orchestration with an identity fabric enables security teams to deal with the complexity of multi-vendor and multi-cloud environments much more easily. It can unify the identity operations of incompatible legacy and modern cloud IDPs. When the goal is to move apps off end-of-life/end-of-service legacy IDPs, identity orchestration can provide several benefits.

It allows an organization not only to move but to improve its identity infrastructure by adding new capabilities like passwordless access and MFA without re-coding applications.

With identity orchestration, enterprises can mix and match legacy, on-premises IDPs with any number of modern cloud IDPs, again without rewriting any target applications.

In addition, identity orchestration can greatly simplify the process of managing policies. Without orchestration, changes have to be written separately in each identity system. This is time-consuming and expensive, and it also opens up the possibility of errors (e.g., neglecting to change one of the applications). Identity orchestration makes it possible to manage identity policies for all applications once instead of having to manage each IDP separately.

Architectural Issues

When deploying an identity orchestration architecture, here are some important considerations:

• Global Application Support: Many orchestration platforms require that applications use a designated IDP. When moving from a legacy, on-premises IDP, this will mean rewriting each application. Look for open identity orchestration solutions that can support any application using any IDP.
• Resilience: Cloud-dependent architectures can introduce a single point of failure that can grind application access to a standstill when cloud access is not available. Instead, an orchestration system should be able to execute policies, rules and configurations locally until access to the cloud is restored.
• Scalability: Avoid SaaS-only orchestration platforms, which are susceptible to noisy neighbor syndrome. This occurs when spikes in other customer activity can result in latency that can impact performance and slow down response times or generate time-outs to access requests.
• Privacy: Make sure your orchestration provider does not require you to store personally identifiable information (PII) on their platform, which can pose compliance issues for organizations that operate in regulated industries.

Today, it has become the rule rather than the exception to embrace multi-cloud, multi-vendor architectures that encompass both on-premises and cloud-based identity systems. For large, established enterprises, the resulting complexity will exist for many years to come.

To accommodate hybrid environments, identity management processes must be flexible and vendor-agnostic. The emerging category of identity orchestration technology can meet these criteria, delivering greater visibility, control and policy automation at a significantly lower cost.