Do we need to Internalize Authorization Before we Externalise it?

To do quick sound check. Good. So thanks for being here everybody on Friday of EIC. It's been a full week and I really appreciate you making time to be here. I'm Peter Kasman, I'm an identity enthusiast. I work at Microsoft where I have the privilege to work on some of the most challenging identity and authorization problems in particular that faces our world and our society. Today. I'm gonna talk a little bit about the externalization of authorization. A topic that's been around for probably 20, 25 years, almost for as long as I've been working.

And sort of reflecting a little bit about what are the, what has been the challenges, but also what is it that we need to change to maybe have a shot at externalizing authorization. And some of that is really thinking a little bit more about one of some of the things we have to go and internalize and figure out for ourselves first. So I'm gonna talk a little bit about the return of externalized authorization. Why now? Why is this still important, right? And why is it so important at this moment and, and what are the big trends that's driving that?

Three things that I think we really need to internalize, really get our heads wrapped around to set us up for success in this space. And then maybe a little bit about what do we need to do next as industry, as technology providers, but also as practitioners, right? How do we make progress on this topic? And hopefully there's time for some q and a. I'm gonna try my best to, to keep to, to the time.

All right, so return of externalized authorization. Authorization has been sort of a bit of a Gordian knot, right? And I think you're probably familiar with this sort of metaphor where it's this ball of intertwined complexity. Authorization is intertwined with our business logic. And we're really sort of been challenged of like, how do we cut this knot? And you know, one way to look at this is to say, well, maybe if we look at this, maybe we've been focusing too much on the individual strands, the technologies, you know, the avac, the P back, the star back, whatever.

But maybe we really need to go back to basics as to what is it that we're really trying to do with authorization. And turns out it's actually pretty simple, right? With authorization, we're really trying to answer three questions. The first one, runtime access control. Does this principle have access to this resource?

Simple, right? We just have to answer that question. How we do it, what technology we choose. It's separate discussion, but it's about this question. Then we also need to know what's the blast radius, right? 'cause now we're getting into risk management. What resources can this principle access? Because I need to know if that principle is compromised. What is my risk and my exposure? Because authorization is also a risk management strategy, right? And then finally, what's my resource exposure?

Give me all the principles that can access this resource because I need to figure out where are my biggest points of vulnerability, right? And so answering these questions, one way in which we would like to do that is to say, well, we need to externalize authorization. And what we mean by that is make the rules, the what we call the policies of authorization external to our code. Separate that from our business logic and be able to analyze and reason over that. And then compare that with things like the audit logs and see if there's any discrepancies, right?

And when you do that, you can start answering these questions. It's actually one of the interesting ways to rethink authorization is this really about data. Perhaps more so than any specific technology, right? Because many of us have multiple authorization systems. Quick show of hands, who operates one authorization system? Nobody. One. How many operate multiple authorization systems?

Yeah, okay. Honest people. I love it There there's a, a joke that goes like, there's two kinds of identity professionals, right? Those that operate multiple authorization systems and those that don't know that they're operating multiple authorization systems yet. Okay?

So, so let's look a little bit at the return of externalized authorization, right? I think there's a couple of things that's changing.

The one, one thing that's now sort of becoming very obvious is that one reason to revisit this quest for externalized authorization is a new breed of threat actor, really advanced capability nation state capabilities. And that's focused on attacking the supply chain runtime environments and actually very specifically exploiting the course grained authorization approaches that we've had up until now, right? Network perimeter. And within that network perimeter, you can do anything you like that is no longer working. And the threat actors have reminded us of this regulation and compliance, right?

Increasingly we have to be able to demonstrate who has access, what can they access, and most importantly, prove it. It's all about the audit log. You can do all of this authorization if you have no audit log, well, it's gonna struggle to prove what, what you're doing increasingly need around business apol agility, right? So things like policy as code, brownfield, greenfield. I think this is the other big thing that we also need to rethink an authorization. A lot of what we talk about is sort of greenfield, right?

It's like, oh bolt this new thing. And that's a sort of, somebody once pointed out to me that's like having a turnkey solution, right? I will hold the key and you can turn the building. And that doesn't always work. So we do have to go and think about what are we gonna do about brownfield, those existing deployments, how do we secure them? How do we externalized authorization even though it may not have been done that way originally.

And yes, of course ai, I sort of reluctantly put it in here, but one of the reasons I do wanna talk about AI is because how it's gonna drive the growth of, of machine identities, microservices, and just a huge challenge at scale, right? We think we're struggling with authorization. Now wait till you have to do this at the scale of ai.

Also, I think we are gonna not just have to think about workload, workload identities and authorization, but probably also about data, right? How do we secure access to data as well? And then another big thing that is coming with AI is the idea of multi-cloud. It's follow the GPU. So many companies are less concerned about where they're executing that than just getting the resources to go and run their AI models at all, right? So I think these are sort of big drivers why we need to go back and continue to revisit this externalization of authorization.

Okay, so before we externalize maybe time to reflect right things to internalize three things and I'll talk about them individually. First, I think we really need to go to stakeholder value. We have not really explored that enough. And I'll talk more about externalizing authentication and contrast to this as well. We also need to think about the business processes, right? Authorization find grant authorization at scale is gonna be really challenging to manage. And so that is something that we need to think through.

How will authorization be integrated into our business processes into our organizations? And how do we bridge things, right?

DevOps, IT admin, CSO office, right? How do we make it so that we have an authorization system that meets the different needs of all of those organizations? And then finally, technology. 'cause I think too often as technologists, we start with technology, but maybe we still need technology. But I also want to sort of, we should maybe rethink or maybe start with these other aspects before we start with technology.

Alright, so stakeholder value. I think you know many asking people here why we need external to externalize authorization. I think everybody here gets it, right? We're identity professionals, it's very obvious to us. But how we sell that and how we convince our peers and the rest of the organization. And I think this is a challenge where we need to think about how we position this in terms of business value. Is it about efficiency? Is it agility, right? The ability to quickly change the rules. Is it about value creation? Are there new scenarios that we can unlock?

Is it compliance or is it simply peace of mind, right? Is that the real value? I've got an externalized authorization system, I can prove who has access to what and therefore I know to have to worry about authorization anymore. Stakeholder value for our IT admins, right? They need visibility, they want control, they want governance, but they do not necessarily want to be in the middle of every authorization policy that's getting authored, right? They wanna be able to review them and they wanna shift some of that left to the IT admin or to the engineering organizations.

The engineering organizations, right? They wanna plan, create, deploy, they're building stuff, but they wanna shift some stuff, right? Right? They wanna shift management governance, they wanna shift that back to the IT admin organization. And finally, customers, how do we think about the value of authorization for customers? Or do we at all, Eve Muller had an excellent presentation about consent earlier this week. And it got me thinking, is that an authorization scenario?

Me authoring, creating a policy about how my data should be used with an expectation that whoever receives that policy will honor it. Setting up things like delegation. So instead of having to define my family for Xbox office, Netflix, any other kind of sharing service that you might have, could I just do that once, delegate authorization to my family members to use these services and then have one place to control that rather than 50 different services? I would like to challenge people here to think creatively about how we can think about authorization as customer value as well.

Now, this is really, really important. Like I'm gonna just sort of as a reminder, as an industry, we successfully externalized authentication over the last 20 years or so. And we managed to do that because we got the stakeholder value piece, right? The business value was clear, all my risk is gonna get centralized in one place. For engineers, it was clear, this is a, you know, a very easy, simple way to integrate authentication so that I don't have to build it every time. So there's an efficiency gain for the IT admins, it was clear, I have one place where I can administer and have access.

And for customers that's a great win. I get single sign on value for everybody. And I think we want that story for authorization as well. So internalized stakeholder value, but also business processes, right? I think one, acknowledge the problem. This is already difficult. It's gonna get more difficult, especially at scale, especially if we're already operating multiple systems, right? One of the things I would say we would have to be thoughtful about is how we connect these systems.

And also to what extent is there actually some layer of abstraction that we can put on top of that when we connect these systems? We have to be really careful. You can have a really state of the art authorization system on one end can be very leaky, right? When you connect that to another system that maybe has still very sort of course grant authorization policies implemented, already talked about managing at scale and then the separation of concerns, right? From a business process perspective, how will you empower the engineers but still leave the IT admins in control?

And then finally, culture. How do we do, or what do we do to get to a place where the NA today it is an unnatural act for an engineer to say, I'm gonna build my own authentication system, right? How do we make that an unnatural act for authorization? Some of the work we're doing in standards I think might help. What if every compute platform had a standardized set of APIs that you called for authorization? Your engineers expected to call those a APIs. And behind the scenes we could plug in the different authorization systems that we needed to serve them, right?

What are the things we can do, not just to aspire to the culture, but to actually enable it? Let's talk quickly about technology. There's lots of technologists here, so I'm not gonna spend too much time on this, but you know, I think the third pillar, the third thing we need to go think about is what technology do we need? Once we figured out the stakeholder value and, and we've thought about these business processes, we need flexibility. And we really need to think about both greenfield and brownfield.

Brownfield is actually one of my biggest areas of focus because there is so much of it, right? I would love to be able to just go and build new things all the time and lots of new things will get built in the next decade for sure. But how we deal with Brownfield is the answer Microsegmentation, service meshes. Is that really the way we're gonna do it with proxy servers? Are we gonna just encapsulate and wrap these existing services?

Or are we gonna adopt a data strategy where we say, well, we're gonna look at the data and we're gonna infer what the authorization policies are if we don't have them explicitly, and we're gonna be doing monitoring and auditing and anomaly detection on those to get some level of certainty, ex friendly to expertise elsewhere. So expertise elsewhere is everybody who's not in this room, the rest of our organizations, our customers, they're experts at something, but not this, right? And so we need to figure out how to make this drop dead simple, right?

For developers, for IT administrators, for business leaders. And and I left that off customers, right? For this should not be a new learning curve or the learning curve should be so hard that it's more trouble to not do the right thing. We need low latency and resiliency.

And, and what this really sort of comes down to is we need to figure out how we push those authorization decisions out to the edge. And I think that's already a well established pattern. We authorize centrally or we, we edit policies centrally. But then sort of that strategy of pushing down and caching also, right? I think this other idea now courtesy of eve, should we be thinking about customers potentially authoring some of their own policies as it pertains to their assets, their data? And then finally, right, it has to be deployable at scale.

My premise is that at least the interfaces needs to be built into the compute interface, a compute fabric, whether that, and it has to be ubiquitous. What if these interfaces, things like Zen became part of the Kubernetes API sets, right? What if it was just there so that when I'm building a new application, I don't have to even think about which interface I'm going to use. I'm gonna use the one that's available to everyone.

Okay, so what next, back to our Gordian knot for all the talk about technology and business process and stakeholder value, don't forget that this is the game, right? We have to answer these questions and we wanna help our customers answer these questions and our stakeholders answer these questions. So we really wanna keep focused on the outcomes, but at the same time, right? There's also practical things we can do as an industry. I think more work is needed around standards in the IETF, the Open ID Foundation and other places. So Open ID foundation, the old Zen working group in the IETF.

There's a new working group focused on workload identity. There's the OAuth working group, right? There is already plenty of opportunity in places, but also open source specifications are great, but implementations that accompany them, right? So how do we think about some of the work that's happening in the cloud Native Compute foundation and other places, right? So that there is not just an interface, a specification, but also an implementation that's broadly available.

On the technology side, I think there's the challenge on how do we get to embed this authorization capability into the compute infrastructure. We need to figure out how we get beyond greenfield. And then the other challenge or opportunity, how do we think about authorization more as a data problem than say a policy or a policy language problem. And then from prac practitioners, I would say, you know, answer the questions and go and internalize these three things. Your stakeholder value, your business process, and your technology. Thank you.

So we, let's spend one minute on questions. We don't have any questions online. Are there questions in the room from what you've just heard about? Yeah. Especially externalizing authorization and strategies to get there. Others questions in the room? If you don't have one, I have one, but Yeah, but it's over there. Just a sec.

Oh wait, I have to have the microphone. For the online audience and for the recording. What do you think is the timeline for authorization?

Like how, how quickly will we see progress? We are making progress now because of the work that's already beginning to happen in the standards bodies. I think my one call to action is, let's go quicker. Right?

You know, I hate to say 10, 15 years. I think the, the opportunity actually is now if we wait until this explosive growth in growth and workloads and machine identities take place and then try to come back with an authorization solution, we're done. Right?

Like I, that's gonna be much harder. So my, my ask on you, David and other people get that all send work going quicker. Let's engage with these different standards bodies.

Let's get, let's get some of this embedded into as much of the infrastructure. And then I think we, the other thing is we do need to figure out what the story is around Brownfield, right? We need a good story at an industry level for that too. But start now. Quick. Quick. Great. Thank you very much Peter. We will see you again later. You will see me later. Okay. Thank you very much Peter. Thank you.