Putting the Four Components of Modern Identity to Work

Alright, thank you everybody. I want to preemptively thank you for your attention, and I want to thank you for your stamina. It's a lot of content at EIC, it's long days, and there's still 48 hours more of content just today alone, so I appreciate you willing to gut this out. Here's the problem. I thought I understood the map of the identity market. I thought I understood what were feature boundaries, what products did what, where did they serve, who did consume them.

But, over the last two years, I don't know, I feel like the map has gotten blurry. Evidence. I defy you to tell me in succinct terms what is access management, what is IGA. All of these things start to be blurry, and I especially defy you to say, tell me what's in an identity security offering. Typically it is whatever the vendor has on the shelf. And the problem is that it's hard to understand what capabilities we are consuming when we use these blurry terms.

So, in some regards, this presentation is me desperate to stop the madness. Here's what I do know. Identity fabrics require modern IAM. We need to think about a modern way to go forward for our existing infrastructure, and so you can think about this talk as a bit of a mental model for what IAM is, especially in the modern terms. There are four components.

Policy, data, orchestration, and execution. We're going to step through each one of these, and we're going to talk about how we can use them.

So, let's start with policy. Policy is the one we are probably most familiar with because we are swimming in policy. All of our tools, all of our business rules, all of it hinges on policy. And we can think about policy as the rules of the road. Everyone needs these. It's how we have an orderly world. And these rules have to be both human-readable and machine-understandable. Why? Because whether it is a human who has to operate against it, a robot doing that, or a human and a robot working together on these policies, they have to understand it.

Not just understand these things and actually enforce these things, but they're going to work together to create them and manage them, to govern them, to understand their impact if we change them, and actually to put them into action. Now, the thing about policy is that it doesn't have just a single place where it's important. For example, our policies have to apply at traditional admin time, what was before use of the credential or the entitlement, applying at run time when we have session creation, and most importantly, at event time.

After we have done the login experience, issued the token, what happens next? There's a lot of events in the story, and our policies have to apply to those too. So in this regard, we need continuous policy. It used to be that we would answer the question, as identity practitioners, who has access to what? The age-old question.

However, this is not sufficient in the modern era. We have to add to this, under what conditions did someone get this access, or this thing get some access? So in that regard, modern IM also requires contextually informed policy. So now we can spend a whole conference on policy, but let's keep it there for a moment. The next layer, data. Bad news. IM has treated data for the last 20 years primarily as an afterthought. Don't take personal offense to that, but it's a reality.

Partially this is true because our identity systems are only designed to operate on data that they can physically connect to. My provisioning system only knows about the things it has provisioning connectors for. My SSO system, same idea. Because of that, it means that that identity system had a very limited view of what is actually going on inside the enterprise. It also means that the data tiers that they used were not built for particularly high volume or high velocity data, and they certainly were not built for multidiscipline data. My IGA system has data here. My SSO system has data there.

It gets worse. We actually gave away the data exhaust, the really interesting things that were coming out of our identity systems and all of its associated value. We essentially tossed this over the transom, so to speak, to our security peers and said, here's some logs, tell me if you find something interesting. We gave up value that should have been ours to represent in the enterprise. This has to change. It can change, and it is changing. Here's what I know. An identity fabric requires consistent and robust data layer. So what's in it? So what's in this data layer that we're thinking about?

Well, we've got the classics, sort of user attributes and sort of organizational structure. No surprise there. A little bit more of extended attributes, let's say. Things around training and certification, for example, skills. Information that might be relevant, say, from a CRM system, if this is a SIAM use case. But that's not enough. We also have to include all, and I mean all, of our admin time, our run time, and our event time data. All of the telemetry, all of our join, remove, or leave events, all of our authentication events, even transaction telemetry.

We're not done, because with this, we can do a lot. But if we actually add security telemetry to this, tell me more about the conditions under which someone was authenticated. If I've got IP intelligence, pull that in. If I've got threat intelligence, pull that in. And then lastly, some of the most exciting things that have been happening in identity, the last thing we need to add to this data tier, relationships.

Our need to better understand on behalf of relationships has never been more important, especially as we look down the lines of what happens with agentic AI, especially when we think about extended customer service situations, especially when we think about death in the digital estate. Problem, even that is not enough, because actually what we want to do, if we want to have this contextually informed policy, is things like duty rosters. Is Ian supposed to be working right now? And fraud signals from our home-grown systems.

And heck, if it's SIAM, I want to know what marketing campaigns are running right now, because it has relevance in the decisions we need to make. So we need even more context. There's going to be something in the way. So if we think about the main pillars of an identity infrastructure, each of them has their own policy and data and orchestration and execution layers. These are not enough, because we actually need other kinds of capabilities, so to that we start to augment them. We start building out our identity fabric.

Tell me, how on earth are all of these things supposed to work in concert if each of them has their own slightly out-of-sync data layer? Everyone has their own vision of reality. How is this going to operate together? But it gets even worse than that, because if you actually look at those data layers, I would guarantee you that about 30% to 70% of data in each of those data layers is redundant and just slightly not like everybody else's. So not only do we have a fragmented view of what reality is, we also have this massive data problem.

So what I believe we need to get to is something that looks a lot more like this, this consistent data tier for my entire identity fabric. Spoiler alert, we can't do that. We can't do that.

Well, a couple of reasons why we can't do that. All of our identity infrastructure has a proprietary data model that we somehow treat as wholly distillate from the celestial beings themselves. This is our most beloved thing, and it's kind of crap. It's a proprietary data model not built by data practitioners.

And again, it's a single view of the world. My IGA system knows IGA, my SSO knows SSO. There is no shared information model. So I have to do all of this mapping and marshalling if I want to correlate this stuff. And what's this blocking?

Well, it's blocking, notably, data portability. How easy is it to swap out identity components in your fabric? Depends on how many fingers you have left because you had to donate one to get through the process. It means we can't have professionally managed data tiers. We are identity practitioners, and we're really, really good at that. We are meh at best at managing data in high volume. But we have our peers who can do this.

Right now, they are prevented from helping us. And it doesn't allow us to bring our own AI models. You have an organization who's already been doing some data science. Having these proprietary data models makes it even harder to then go bake off different AI models against each other. So in my opinion, it is high time we actually go standardize some part of the IAM data model. Full stop. What we need to do this? OIDs. Self-explanatory, right? We need not this kind. This is an OID from LDAP land.

And if anyone knows what this is the specific OID for, you will win a prize if you come see me after the talk. No, what we need is an open IAM data schema. And this is something that I've started making a little bit of noise about, and people have started joining the conversation.

You, too, can join the conversation. Over at IDPro, in the Slack environment, open IAM data schema. I am actively looking for people to help me in this quest because I think we can unlock an enormous amount of value for everybody. So that's data.

Next up, orchestration. Okay, to talk about orchestration, we actually have to talk about replacement cycles. How frequently do you replace major components in your identity fabric? The average in talking to people is about once every 10 years. Once every 10 years, you muster the political and budget will to do the extraordinarily painful thing of changing out a major system and identity.

Now, because of that, you can't wait nine more years if you just bought something because you need capabilities, which means you have to augment what you have with other capabilities. That, by necessity, means you have an identity fabric, right? A confederacy of fit-for-purpose services that actually help you do identity throughout the enterprise.

Workforce, consumer, B2B, B2C, it doesn't matter. In order to have a fabric, you actually have to orchestrate all of those bits working together. And you got to do this effectively in near real time. But that means we have a little bit of a sticking point.

See, because identity right now has got a couple of things it knows how to orchestrate. Joiner, mover, lever, login or verify, and token issuance.

Arguably, that's just four things. That's four moments in the enterprise lifecycle when we can apply identity controls. That is a piano with four keys, and that will not make us a very popular pianist. Because we have to add to this the ability to bring identity controls when context changes. Whether it's business context, IT context, security context. And we need more than that. We actually need bookkeeping, which sounds kind of boring until you realize how complicated our lives really are. So think about this. You have a ticket gets created in ServiceNow.

It triggers some provisioning subsystem to go do a thing. Hopefully, that gets provisioned. Then the user account's updated. The person does their thing. They close the ticket. The provisioning system ought to remove that access, because we're all heading towards zero standing privilege, right? And then the account should be, well, successfully removed or the entitlement's removed. This spans a whole bunch of systems, none of whom share a log.

So we need this sort of bookkeeping to understand in this orchestrated way in our fabrics that the things we actually want to get done happen and happen successfully across the fabric. So we actually need orchestration and bookkeeping. Okay. Last up. Execution. The execution layer is where our identity fabric actually meets the enterprise. It's how it reaches out and actually affects change in the enterprise. You know this well. This is brokering SSO or provisioning a user.

Now, this work, as you know, it's hard. It's nuanced just because there's standards doesn't mean it all works exactly how we hoped. And increasingly, somewhat frustratingly, it's also commoditized in a lot of ways.

Now, to be clear, there are differentiated use cases. For example, when I do open banking, I'm going to need support for FAPI. And in order to do that, my existing identity fabric might not have that capability, which means I may have to go actually procure, spend some money to get that capability. But for common use cases, SSO to common apps, provisioning to common SaaS applications, let's say, social sign-on, you absolutely should not be spending money on this. These are table stakes, and if you're not getting them sourced through how you're receiving technology, you need to look elsewhere.

So that's the execution layer. Okay, so we have these four things. Ways to think about our identity fabric. Ways to analyze what we can and can't do. Let's actually step through that. So we'll take the four things, policy, data, orchestration, execution, and we'll take one of our capabilities in our identity fabric. Let's take user provisioning, for example. And we can actually walk through this stack. We can say, what kind of policies are in there?

Well, we have provisioning policies, we've got some configurations, we've got some birthright entitlements. Okay, cool.

Data-wise, well, data, what data does it consume? Maybe some HR stuff, accounts and entitlements, and it produces access request information and some provisioning event data. Great. Orchestration, what can it orchestrate?

Well, it can orchestrate JML based off of HR. That works. It knows how to orchestrate access request workflows. That's good. And then execution, what does it got?

Well, it's got connectors and SCIM and a bunch of other things. So this gives me actually a breakdown at every sort of layer what a capability, just one inside of my identity fabric, can provide. And you can repeat this process. So we could do this again for, say, single sign-on.

Now, as we step through this, we may find, hey, I have a need to describe and affect a certain kind of policy and nothing in my fabric actually does it. In fact, I can take the same methodology and I can look at my admin time capabilities and my run time and my event time capabilities and look at where I have abundance of capability and where I have gaps. And I can run specific use cases through the same analytical process and understand what is the state of my identity fabric. So before I was doing my current job here at Signal, I was at Salesforce.

And Salesforce was a pretty remarkable company because it had a habit of launching products. And the name of the product would change no less than a dozen times before the name actually became public. So if you were a product manager and someone in marketing came up and said, hey, guess what? Your product name is now Taco Force. You're like, I don't, I'm not sure if I'm comfortable with it. What you learned was don't panic because the name of your product was going to change a gazillion times before it actually got out the door.

What was important was to focus on the pains that this product addressed, what capabilities did it bring, and what outcomes did it actually render for the customer. And if you focused on that, you could kind of ignore why the heck product marketing decided to call your product Taco Force. The thing is, that habit, it's really handy in the identity market right now. Things are blurry right now.

And so if you focus on what are the pains the business is experiencing, what are the capabilities I think I need to bring to bear to address that, and what are the shared outcomes we want to see, as opposed to worrying about, is this access management? Is this identity security?

Like, focus there. That's a much better way to think about this complex thing that is our fabric. And the reality is, because of especially economic realities, we now know that augmenting and enhancing is a way better approach than trying to rip and replace.

Like, that is not a viable modern strategy. It's all about our augmenting. And that means it's all about identity fabric. And you can use this methodology that I laid out to think about and see where do you have strengths in your identity fabric? Where are places that are shortcomings which you may want to address? And this is all using the four components of modern IAM, policy, orchestration, execution, and data. And with that, thank you, everybody. Have a great EIC. Thank you. You said you were going to meet your target. I always meet my time. 118 slides. It didn't feel like that.

Maybe it felt like 117, so it's good. Thanks so much, Ian. The one question I wanted to ask you, though, for organizations that have legacy IAM systems, which of the four should they tackle first, or is it kind of like a bit of everything?

Well, it goes back to what are the pains that the business is most expressing right now, right? You'll see a board will say, like, hey, look, I saw that MGM breach. That can't be us, right? That can't be us. And that all came from maybe a misuse of privilege accounts. Let's start there, right? You will get clear clues from the pains the business is expressing on where to start, walk that model, and you'll then know what components you need to focus on.

Okay, great. We've got a question from the audience. Data collection and gathering always has to serve a purpose. So how do you progressively leverage the data elements you've alluded to in your talk? What's interesting is that if you start by thinking about policy, then you will get hints as to what data you actually need. If I know I need to express a certain kind of outcome, I need to affect a certain kind of outcome, I need to build policy to that. That policy will be very clear about what's the conditional information I need. So I need IP intelligence here, and I just need that.

Or I need to understand an individual's journey through a customer lifecycle. Great, I'm going to need specific things there. Follow the policy. It will point to the data you need to collect.

Great, thanks. Please give it up again for Ian Glazer.

Thank you, everybody.