PART 2 : Why Modernize Identity?
February 7, 2020
What Are the Challenges When Moving to the Cloud?
In my last post, I talked about lean customer development, the discovery and validation process we’ve been pursuing these last few months, and the challenges we discovered during those interviews.
To quickly recap those challenges:
- Multiple clouds drive multiple identity-specific problems.
- Identity silos are propagating across on-premises datacenters and cloud environments.
- SAML and federated SSO only solve part of the problem.
- Centralizing identities in highly distributed environments is nearly impossible.
- Legacy IAM products are reaching their end of life.
When I wrote the title for this post, it seemed almost like a rhetorical question. Why wouldn’t you modernize identity? After all, the challenges we’ve articulated here are real and urgent.
How you solve some of these challenges necessitates making really big changes across technology, organizational process, and people. It’s good to have clarity about exactly Why you should make these changes before you jump into How to make them.
Let’s explore the Why a little further.
Legacy Characteristics and Cloud Requirements
For me, this whole exercise has been a refresher course. I’ve been in the identity and security space for 20 years, building three iterations of on-premises identity systems before moving on to building planet-scale cloud services.
I started with a simple question: why aren’t legacy identity systems simply adapting to cloud? At the risk of sounding obvious, it’s because cloud has characteristics and presents requirements that legacy identity systems don’t meet.
I put together this chart to compare the two according to four broad categories:
When you compare the needs of cloud services against the capabilities of legacy IAM systems through these four filters, the deployment, integration, user, and policy models, it becomes immediately clear that those legacy identity systems just won’t do. It’s not that those products are bad - many were quite innovative at the time - but the push of innovation that cloud needed took place in other areas and found a home in other products such as SaaS and public cloud.
How Identity is Delivered in Legacy Environments
First, we need to call out the ways users interact with a typical enterprise app became, over time, deeply dependent upon legacy identity systems. The configurations that create the user’s experience of interacting with apps is spread across the infrastructure. There are configurations in the web tier, the app tier, the data tier, and in the identity systems. These configurations are pretty static and so the flows they enable don’t adapt well to change.
As we move from left to right, you can see the typical pattern.
- An identity-management system creates users in a user store such as Active Directory.
- When a user tries to access an application, she is challenged by the web access management system using a custom login form.
- Credentials are checked against the directory and, sometimes, the authentication scheme has custom multi-factor authentication layered on for extra security. In rare cases, physical tokens may be used.
- Once the user is authenticated, the identity-management system sets a proprietary cookie and sometimes adds additional attributes into HTTP headers.
- An Agent or Proxy deployed in front of the app is responsible for enforcing access control, including the authentication challenge at the beginning of the flow and the authorization check done subsequent to the user getting access to the app.
- The app usually consumes the proprietary cookies and headers to give the user access to the app. In some cases, more granular URL based authorization policies may be applied. In very limited cases, the app may consume SAML assertions.
As I mentioned, all of this is set up and managed through manually performed configurations. It’s rare to see any infrastructure automation used to manage the environment. Servers, especially those in production environments, are often provisioned for peak capacity.
The result is a lot of complexity, many manual tasks, little automation, and a fundamentally inefficient deployment model.
What Are the Benefits of Modernizing
During our customer development exercise, we asked customers what benefits they expected from a modernization exercise. Over our dozen or so interviews, six outcomes came up over and over. And these answers are useful for understanding the Why of modernization.
- Becoming cloud native results in the ability to adopt modern architecture patterns and lets you focus on bigger digital transformation initiatives rather than on “keeping the lights on”.
- Saving money is a big benefit. A cloud service provider spends a lot of money on data centers, infrastructure, resiliency, and security. Why spend your own money when you can spend theirs?
- Get more done, faster. Nearly everyone we spoke to was looking for ways to prune their workload and accomplish higher value tasks more quickly.
- Customers want access to the innovations available on a variety of cloud platforms, but don’t want to get locked into any one of those platforms. Cloud offers a degree of choice and flexibility that wasn’t available in legacy and everyone is eager to make the most of that choice.
- Most customers are looking for ways to future proof their cloud investments, whether by extending their existing investments with hybrid configurations, or by easily scaling supporting infrastructure as they grow.
- Some customers saw modernization projects as a way to leap to the cloud and an opportunity to break out of stalemates caused by overwhelming technical debt, risk aversion, and slow decision making.
Now that we’ve developed a clear picture of Why customers modernize, the next step is to look at How. We will take a look at two use cases – Lift & Shift and Move & Improve – that often serve as the next steps for adopting a more modern, cloud-based approach to identity management.
To view all the posts in this blog series, go here.