AuthZEN: the "OpenID Connect" for Authorization [Introductory]

I'm David Brossard. I'm the co-chair of the OpenID AuthZEN working group. And I'm Axiomatics AB. I'm Cerbos. I'm not a co-chair of the working group.

I'm, like, on a stool in the corner somewhere, trying to reach the table. The naughty stuff. That's the one. Yeah.

Alright, thanks for attending. I've got some good news and bad news. The good news is lunch is around the corner. The bad news is you've got to sit through us before you get to lunch.

Alright, so both of us, and Mike and Alex before this presentation, we've all been working in authorization for a really long time, right? And as a whole, we tend to think that authentication is a solved problem, probably because the grass is greener on the other side. We don't really know if it really is greener. But as a whole, we've kind of tackled authentication. We know how to have a central IDP. We know how to establish SSO, do MFA. It's relatively more or less mature.

Sure, there's always more stuff you could do, pass keys, and so forth. But pretty much, there is one team within the enterprise that deals with at least workforce identity. There might be a separate team that deals with consumer identity. But generally speaking, it's a largely solved problem. Don't throw tomatoes or anything. I did not write that slide, by the way. I do agree with it, right?

However, authorization is broken. Authorization is broken because it's actually a hard topic to tackle. It's not something that is entirely in the hands of the IAM team, right? It's something that, yes, the IAM team handles a bit of it, right? The identity side, the one-sided equation. But it's also something that the app owners, the business analysts, the compliance managers want to dabble in. And it's actually a human challenge.

And so, what's happened historically is that you write different apps, and you're going to build your authorization logic inside of the app. It's baked into the app. And it's baked into your Homegrown apps. It's baked into your SaaS apps. It's baked into your COTS app. It's messy. It's a bit like spaghetti. There's a lot of traditional access control ways of doing authorization. If you thought you were going to be learning about RBAC and KBAC and TBAC in the previous presentations, I'm adding GBAC, group-based access control, or group-based ACLs, of course.

I mean, who does not know ACLs? And then there's many more BAC acronyms. The problem with these ones, not the ones that Alex and Mike were mentioning, is that they force you to compensate for the lack of granularity, the lack of transparency in the app. So you end up writing spaghetti code. I love spaghetti, just not my code. And it's actually a two-fold issue. Number one, you end up with inflexible apps and bad security. And number two, you waste time developing those apps because you have to reinvent the authorization layer.

And show of hands, who here would think of building a new app and baking in authentication and user management and passwords in those apps? No one. Thank you. Great.

Oh, you, sir. Yes? And your password is 123456? Okay.

So, we at OpenIDL Zen, and we the vendors that are part of OpenIDL Zen, and many other standards and communities before us, we really believe in two things. One is externalizing authorization from the apps, from the SaaS, from the COTS, number one. And number two is also moving it to runtime authorization. If you go back to the previous slide where I was talking about RBAC and groups and ACLs, these are admin time authorization where, as a user is created, as a user is authenticated, we give them entitlements, and then they can go do whatever they want to do, right?

A static authorization, long-lived authorization, not a great idea. In OVZen, what we say, we want to decouple the authorization logic from the app, and every time you want to do something in an app, in a service, in an API, we're going to be calling out to an OVZen interface to determine whether access should be granted or denied. And that's going to allow us to build a central, logical authorization capability within the enterprise. And when I say central, I don't mean that there's only one service in the whole enterprise.

What I'm saying is it's a service that you can consume, that many apps can consume to determine authorization. And by the way, when we think of the term authorization or runtime authorization, it applies to SIAM, it applies to workforce identity, it doesn't really matter. What Mike was presenting with the tokens is actually really interesting, because now he introduces the concept of access delegation, that's also something that we can do. This ties very much back also to what Alex was talking about with the PEP and the PDP for the agent side of authorization.

If you wanted to break it down, the dimensions of modern authorization are externalized, have I mentioned externalized already in that presentation? Yeah? Sign-grained, being able to look at multiple parameters, so attributes we call them. It's even more interesting when there are signed attributes, going back to TBAC as Mike was mentioning.

Runtime, don't rely on the admin side of things, on the admin time side of things. And also relationship aware, so that goes back to REBAC and KBAC as Alex was mentioning. And if you look at all the standards, this is not new. Like I said, all of a sudden we're trying to streamline things, but it's not new. We're not building this in a vacuum. There was ZAPL and Alpha before us. There was Zenzibar, a Google paper that came out in 2019. There's NIST, NGAC that was developed later, which is very much a REBAC system. We're trying to straddle those worlds. We're trying to abstract away.

So Alex here might be doing authorization one way. I might be doing authorization another way. But we want to make sure that as PDPs, you can talk to us in the same language, that you don't have to go through vendor lock-in or tearing parts in and out and so on and so forth. There's a lot of open source capabilities out there as well. Open policy agent is possibly the most famous ones. But CERBOS, which is the one that you're developing, Topaz, or a couple other capabilities. Cedar is the AWS one as well. So in the charter, we have three main missions. We're two years old.

We started in the summer of 2023. The first thing that we tackled or in the process of wrapping up is the APIs. We have three APIs in mind, three ways of querying for authorization. Number one, ask a yes-no question. Can Alice view record one? And there's a variant to that. You could also do batch questions. So can Alice view, edit, delete record one? Or can Alice view record one, two, three, four, five? How far should I go further? The second API that hopefully we'll get to in the demo is the search API. Because sometimes you don't just want to ask whether a user can do something.

Sometimes you want to ask what they can do. I know I'm Alice. I know I want to view. What is it I can view? Tell me which records I can view. And then the search API is going to say, oh, record one, record two, record seven, so on and so forth. And then the third API is a variant of the second one. We call it partial evaluation. It's pretty much the same question. But instead of returning the actual items, you're going to be returning constraints. You're going to be returning conditions. So tell me which records Alice can view.

Oh, records in sales or records in draft mode. So these are the three APIs. And we believe that if we mature those APIs, if we standardize them, we're aiming at fall, roughly summer, fall of 2025, then we can turn around and go to the COTS and the SAS of this world and the app developers and say, hey, don't reinvent the authorization wheel. Use those APIs. Second step in OVZen, we'll be looking at events.

Working a little bit with another OpenID group called Shared Signals and understanding how we can share authorization information over events or how events can enrich authorization decision-making process. And the last step, perhaps the hardest step, really, is going to be policy management. Policy in the broad sense. Both Alex and I here, we're policy-based people, so we believe in policy. Alex in the back is a graph-based person, so you probably got it from his presentation. But we mean policy in the abstract sense, in the plain old English sense. This is what the request response looks like.

It's a very, very simple JSON payload. This is for the binary API. You ask a very simple question. You get a true or false back. We have a lot of samples online. We have a postman collection that you can browse. I really recommend that you do that. And then I'm going to hand it over for a demo, right? Proof is in the pudding. Cool. Thank you. Can I break the demo? I'll do the slide in here and then swap over.

So, yeah, just looking at this payload structure, print park is a term that's kind of used, prints for action resource context. The first draft of the spec, we landed on this model. So subject, action, resource, and then an optional context object. So subject here, we're talking about we're going to define this as a user, maybe it's a machine, maybe it's a workload, maybe it's an agent. It has an ID. Potentially could have some attributes associated with it. The action, what action is that identity trying to do inside of the system, and then what resources that action be done upon.

The result is a simple Boolean for now, a decision, true or false, whether it should be allowed or not. And the key thing is us as a bunch of vendors kind of said, like, what this protocol, what this messaging format looks like isn't really the differentiator. How you manage policy, how you give audit logs, how you give decision logs is where we kind of see the value of kind of the products on top of it.

And this is the underlying plumbing that we want to make sure it's very easy for anyone who's on the architecture or the business side of things can go and adopt an externalized authorization solution with confidence that you're not locked in and can make sure you can take advantage of these standards. Do you want me to be a clicker? So how have we kind of been improving this? As David said, we've been doing this for a couple of years now. And along the way, we've hit certain milestones and we've done interop events.

So the very first one we did was around that initial use case of a to-do application where a user is trying to create, complete, edit, delete a to-do, and we have a demo application. And over the last couple of years, we've done an interop event at Authenticate. We've done Identiverse. We did one back at Gartner as well. And we're reaching these kind of milestones where you tick off each part of these specs. So this first demo application, we have a couple of users. It's modeled around the Rick and Morty cartoon, if anyone has watched that.

I've managed to do this demo many times, and I've still not watched an episode of it. But we have these entities, and a user has a role. They're a viewer, editor, an evil genius, kind of essentially an admin. The resources we're interacting with are to-do items, so typical to-do checklist, and the actions we have are view, create, delete, or complete that to-do. So who was here last year by show of hands and came to an Authsend talk?

Okay, not that many. Cool. So this is our interop application. Dead simple. Obviously not going to ship this production and go and raise loads of money from VCs. But a simple environment where we can go and enter to-dos. Behind this, there's a sort of back end, and we have some configuration where we can basically define how is the authorization checks done behind this system and behind this application. So we can actually go and pick a authorization PDP. In this case, it's set to axiomatics.

That's going to go on the back end of this UI to go and do the checks before it processes an API request. The interop event we did last, we added in a new set of components to the stack where we've added an API gateway in front of it as well. So we can actually go and select one of the different API gateways, and I'll show you who those are in a second, that have implemented the spec. And then at the gateway level, we can actually use a different PDP. So in this scenario, there's a service PDP, so axiomatics and service. And so I can go and sort of make calls, and that action will go through.

Showing authorization is a really boring demo. I apologize. It just works. But the important thing here now is I can actually go and select a different authorization PDP to do on the back end. So now let's go and say topaz. And at the gateway level, let's go and use signal, let's say. So I can say hello again. There we go.

Phew, it worked. So here we've now just swapped out literally the end point, the PDP end point, that both the back end application and the API gateway is using to authorize that check without us having to reconfigure API payloads or anything like that. So using that standard, we've connected this application together. We've authorized it both at the API gateway level and also down at the application back end level to go and wire these things up. And it's all completely sort of interoperable.

And what's cool with it is that topaz, as an example, is a graph-based product, so the way they configure policies is one way. Maximatics and Serbos, we use JSON policies, and so we work in a different way. But that doesn't matter from a request-response perspective. It works the same way. Exactly. And so what do these kind of payloads look like? You saw a kind of example earlier, but that web application is just a React application. It sends requests off. We have a number of API gateways. The example I showed was Envoy, but we've got others on board as well.

Inside that gateway, it is forming an authsend request. So in the payload, we have the subject, which was the JWT subject in this case. The action is just the method, and then the resource is the actual route we're trying to access. That went off to an authsend-compatible PDP. It made an authorization decision, yes, allow the request through or not. If it does allow the request through, the API gateway then passes it off to the back end, the actual back end microservice in this case, for that to do application.

And now we send another authsend request off to a compatible PDP, but this time the action is the actual business use case, the actual business action being done against that to-do item. And there's some attributes associated with it now, for example, who's the owner of it. And then that returns back a decision, and then results go back. So this is a good example of defense in depth as well. In authorization, there's no requirement that you should do checks in a single place. You can do checks in multiple layers in multiple places.

Look at the same question, or in this case, different question, right? The medium-grained authorization and the fine-grained authorization. You have that flexibility. Let's see. So who have we got on board? For that first interop, that simple, basic, can this user do this action on this resource from kind of the application layer, many logos on there. Hopefully you recognize a lot of those. And we've had a few iterations of the draft where we kind of tweaked the structure a bit based on feedback from, predominantly in this case, other authorization vendors in the space.

But the next evolution we took was back in March of this year at Gartner in London, for those of you who were there. And we've now added a few more policy decision point vendors in place, or projects in place in some cases, because they're just open source. And then we've got API gateways that are compatible as well that have implemented a hook or a minimum of proxy to do the authorization check at the API gateway level.

So AWS, Envoy, Kong, Tyke, Zooplo, WS2, many of which are here, and hopefully many of you are customers of. So where do we go next? So later this year is Identiverse. I'm sure many of you are doing the identity gauntlet from Berlin to Identiverse again this year. And we want to tackle that next use case, which is the search API. So I now know who the user is. I now know what action they want to do. What resources can they do that action upon is the resource search scenario.

Or there's the other model, which is, I know a user, I know the resource, and I want to know what actions they can do upon it. And I want to get back the list of those actions. And then the third scenario is, which action... Which resource? I always get the mixed job. So which user? Which user, yeah. I have the resource, I have the action, which users can do this particular action on it? So you have a slightly different interop application this time, but it kind of ultimately works the same way.

There's a front end, it's making calls to a PDP, but this time the PDP or the PIP or whatever architecture each of these systems works upon is going to go and fetch the answer to those questions. So we have data sets in here. We have some subjects. They have an ID, they have a role, they have a department. And then there are resources, in which case it is all Shakespeare, which are associated with departments and have owners in this document. And then we have some notional policies that each of the PDPs needs to support.

So if a user can view a record in their department, or if they own it, things like a manager can edit a record based on their department. So behind this, and this is the first outing, I guess, of the new demo application that we'll be doing at Identiverse for each of the supporting solutions and PDPs. And this is showcasing a couple of things that are coming in the next iteration of the spec.

Firstly, that search demo. So I can say, here's a subject, here's a resource, here's an action. What do we get back? And really the quote-unquote interesting bit is what we see on the right-hand side here. So we can see the actual AuthZen request going off to the PDP, and then we can see the response that comes back. And this is the current draft of the search API for resources, subject search. We know the subject, we know the resource ID, we know the action. We want to get back the list of subjects that can do that particular action. And the third scenario is that action search.

So we know the subject, we know the resource, what actions can be performed on that resource or allowed by policy on that resource. That's the search API, and then also at the top in that bar is the first outing, I guess, of the discovery API, or the metadata API spec that we're putting in place to how does a system interrogate a PDP to determine what endpoints it supports is coming in also. So in terms of the roadmap, as I mentioned at the start, we've ticked off evaluation and evaluations, so kind of the batch scenario.

Those search endpoints is what we're actually working on and doing that next interop in Vegas. And then the discovery mechanism, there's already a draft landed in the spec for that. And then the wider roadmap, we're going to start tackling partial evaluation while that's very much underway. Definitely a lot more complicated use case and specification that will come. But also starting to look at profiles. So how do we put a profile on top of this spec for parsing API gateway or ultimately HTTP attributes in a standardized fashion as an authoring request?

And then going on to event delivery, so working with the shared signals, working group for a profile for how that would get pushed down into a PDP or a PIP or a PEP even. And then also looking at IDP profiles. So what is the standard AuthZen mechanism for getting back, say, claims or scopes that need to go into token at token minting time using AuthZen? And there's a complete roadmap which you'll be able to find. I'll put some links in a second.

But in terms of call to actions, really, if you're on more the vendor or the implementer side of things, making sure you start thinking and architecting around an AuthZen-based authorization control plane for your enterprise. So if you're building an identity stack inside of a business, having this idea that authorization is an externalized concern inside of your environment, and making sure that all your applications, initially, obviously, your in-house ones, that potentially you can change the code yourself, start using this externalized authorization approach.

And then really the big one from an AuthZen perspective is start demanding, or at least asking nicely maybe, of your off-the-shelf or SaaS providers to become AuthZen-compliant. We want to get to this world where setting up externalized authorization is as simple as setting up, say, SSO for an off-the-shelf application, or SaaS application, so that you can tie it back into your control plane. It's much like you can control your identities, your IDP, you can control the authorization logic as well by leveraging the AuthZen-compliant positive decision points and authorization stack as well.

So where to find us? All the OpenID links are there. Please come and join the working groups. We do calls on Tuesdays and alternate time zones to make it easier to cover the world. We have the Slack channel as well. All the meeting notes, obviously, are active. And then David and I are around. We've got a booth upstairs. We've got a candy bar at the service booth. We can come and chat. And we have a secret session tomorrow morning. If you're interested in getting your hands dirty with AuthZen, come see us. We'll tell you where it is. Cool. Okay. Exciting stuff.

Being an engineer, I'm going to ask one question. Scale can be hard. All of this is going to work when things are counted in the dozens. The Indian railways are the largest private employer in the world. There's militaries that are bigger. But they have 1.7 million employees. What do you do about a query that might return 1.7 million results? Yeah. So there's actually two answers to scale. First of all, scale for the PDP itself is not a big deal. The runtime scale. Apart from the search. We'll get back to search in a minute.

Scale, however, is a big deal in the control plane, right? How do you scale the fact that you want to write policies for a company that has 10 different sub-businesses?

You know, a bank, a retail, wealth management software. So scale, I think this is how the different vendors will compete and differentiate, right? We'll find ways of allowing collaboration across policy authors. But back to your point, though.

Scale, for the list of employees, we have a pagination feature in the API. I know that if it's 1.7 million, that's one heck of a page. But we follow standard pagination mechanisms.

Alex, do you want to? Yeah, I mean, exactly that. I didn't show in that version, but the spec has pagination tokens built in. All right. Thank you very much, gentlemen. Thank you.