Four Components for Modern Identity

Posted

For the last 6 months or so, I have been struggling with market definitions in identity and access management. I used to understand markets such as identity governance and administration and access management; I understood what the feature boundaries were; I could map vendors to those markets. But honestly, lately, I feel like those maps and those boundaries aren’t as accurate as they once were. So, in some regards, this post is my attempt to work through ways of defining what IAM looks like in the modern era, what parts should enterprises be willing to pay for, which are table stakes, and where is this all going.

There is change in the air; people are willing to consider new solutions and new architectures. What follows is a reframing of the enterprise identity space, one not based on “classical” market definitions, instead one based on capabilities, and it starts with identifying the four major components to new world of identity:

Policy

Every identity system needs rules of the road to follow, and policy are those rules. Whether those policies are built by practitioners’ hands, written by AI, or some combination of the two, all identity systems require some form of policy. Policy is more than just the maintenance of the rules of the road. It includes both the evaluation of those rules as well tools to describe and make actionable the impact of those policies. The data over which a policy is evaluated will differ based on the kind of identity system and, obviously, the data available to the evaluation engine. Furthermore different kinds of identity systems will optimize their policy tools for the outcomes they want to achieve e.g. a user provisioning system’s policies and policy management tools will look quite different from an identity provider’s.

To be clear this isn’t grandma’s policy administration layer of yore. The tools to create, view the impact of, and places to apply policies are all modernized.

In this layer I including both visualization and translation, which depending on your perspective, are One and the same. Too often when we talk about a system sharing the results of a process, we speak of “visualizing” the results. This is limiting for a couple of reasons. First off, it doesn’t serve people with visual impairments well, nor does it help people who learn by reading versus viewing images. Second, it rules out other ways to transmit information; it ignores the power of conversational design. Generative AI and LLMs are about to blow our minds when it comes expressing information in different ways to suit the consumer of that information.

And those same technologies will begin to address a crucial problem in digital identity policy management – the lack of understanding what a policy actually does. LLMs ability to summarize information shows promise; I hope the day is not too far off where I could give a model a list of entitlements and their descriptions and have it summarize what a person could do if they had all of them. This is a two way street as well… I very much want to be able to say “Build a birthright policy for non-SOX material systems for all full time employees that enables them to do the following things as well as ensure they cannot do this other list of things” and then have the system suggest a policy back which I can amend as needed.

And we should fully expect that different kinds of identity systems will employ different generative AI models to suit their needs. Likely this will become part of their differentiation. But what I have no idea about is how enterprise buyers will conduct competitive bakeoffs in the future… how I test one vendor’s user provisioning policy AI against another… yeah, no ideas there yet.

Orchestration

I posit that the replacement cycle for an enterprise SSO provider, IGA system, and PAM system is about every 10 years. It might be a more like 5 to 8 years but it is definitely not 1 to 3 years. The implication is that if you need capabilities that one of the three “major” components of your identity infrastructure do not provide, you need to augment it until such time as you can replace the relevant major component. And this gives rise to a pragmatic need for an identity fabric – a confederacy of fit-for-purpose services that work in coordination to augment and extend the reach and capabilities of the IAM infrastructure.

The only way that an identity fabric works is if its components can be orchestrated. That orchestration has to include “bookkeeping” services… meaning the system that provides orchestration also tracks the entire transaction across all of the components in the orchestrated action. For example, to can report out that:

  • a ticket entered ServiceNow
  • which triggered a policy evaluation to determine appropriate access
  • which in turn flowed to a user provisioning system for execution
  • that execution was successful
  • when the ticket was closed in ServiceNow, the user provisioning system removed the granted access

Without a complete transaction view, the identity and security teams have to piece together the story of why someone got elevated access, and we all know they have way better things to do.

To me orchestration, informed by policy, is one of the most interesting “new” areas of identity. In theory, orchestration in (re-)emerging identity platforms ought to be better than their best of breed rivals… but I’ve seen this best of suite vs best of breed movie twice before and it doesn’t end well for the platforms. That bad ending often has to do with the limitations of orchestration within the platform. Anyone want to bet against me on this?

Execution

This is where the rubber meets the road so to speak. The execution layer is where we identity nerds have spent a lot of time. This is where identity standards come into play. The execution layer is where a component in your identity fabric actually does the work, be that work brokering an SSO, provisioning a user to a target system, issuing a token etc.

This work is hard, nuanced, and increasingly commoditized. There are absolutely use cases where you need a differentiated execution layer. For example, imagine that your business wants to get into Open Banking and your identity provider doesn’t support all of the OpenID Connect FAPI profiles; this situation calls out for a specialized execution component in your identity fabric, one for which you likely will pay extra. But for down the middle use cases like brokering SSO to common SaaS apps, providing social sign-on, provisioning popular enterprise services, you should expect that you aren’t charged for this; these are table stakes.

Data

Last, but by absolutely no means least, is the data layer. For far too long data has been a bit of an afterthought in the identity world… Well, more accurately, two things happen with regards to data. First, identity systems only thought about using the data that they could either generate themselves (e.g. logs) or data they could get via the execution layer (e.g. entitlements reconciled from a target system.) This is a reasonable position, especially given this position was established some 15 odd years ago. Second, identity systems did little with the data they generated, and instead tossed it over the transom to security in the form of logs exported to a log management system. This too was reasonable in only because identity systems were never designed from the ground up to consume high volume, high velocity, and multi-discipline data.

That has to change; that is changing.

An identity fabric cannot be successful without a consistent and robust data layer. There’s no sensible way for a fabric to operate in a coherent way unless all of the components are reading from the same sheet of music, so to speak. I am seeing a lot of creativity around emerging data layers for identity fabrics. Newer vendors are paying close attention here and I expect a new wave of innovation focused on the identity-related data. Our peers in security have had the notion of security data lakes for a while now, but there’s not really a concept of an identity data lake. The companies who have some approximation of it had to build it themselves at significant cost. I have a feeling that the economics of this are about to change pretty radically. When that happens one should expect a follow-on wave of innovation with regards to the policy and orchestration layers.

The tricky part is whether you’ll end up with multiple identity data lakes – an objectively bad outcome – or whether a singular lake will provide domain/activity-specific materialized views of the data. No vendor, as far as I know, is specifically targeting being the data lake that powers the entire identity fabric; similarly, I don’t know of a tested (aka battle hardened in enterprise) and economically feasible data lake deployment model optimized for the identity world. This is what the kids call an opportunity.

Ok so, now what?

This 4 layer model for identity helps think about existing enterprise identity architectures and it, I think, helps practitioners focus more specifically on which components they want to improve or replace. I’ve got a few more things building off of this framework. In the coming weeks look for:

  • some examples of this model being applied to systems like user provisioning and single sign-on
  • a radical idea about workforce identity data
  • an exploration of how this model and is relationship to admin-, run-, and event-time use cases

While there is still more to come, I am excited to get the industry’s feedback on this now!