Modern Authorization: The Next IAM Frontier

Thank you, Graham. Hi, am Ary Gaze. As Graham said, I'm the co-founder and CEO of aer and I'm very excited to talk about modern authorization and why we think it's a very big deal.

First, a little bit about myself. I've spent over 30 years building software for developers in the last 15 of those building cloud platforms. Also long history and identity and access all the way back to the early two thousands of Microsoft where my teams worked on long forgotten things like W Security and WS Federation and saml, and you know, things that laid the foundation, shall we say, for the modern identity stack spent the last 10 years working on open source.

And when I'm not doing startups, I'm skiing, although I'm told by my European friends that what we call mountains in North America you call hills. So one day I aspired to to to ski or mountains. So let's start with a brief overview of what I think is the state of I am. Identity is mostly a solved problem. Gone are the days where every SaaS app had its own user ID and password. Of course. Now through the magic of OWA two and O I D C and SAML and J W T, we have a, an interoperability fabric so that we've transformed identity from an an N times M problem to an N plus M problem.

What do I mean by that? I mean that when you add a new user, they have access to all the applications that speak these protocols. And likewise, when you add a new application, all your users can log in when they have access, access control, completely different story. It's a complete mess right now, it's an end times them problem. And I would venture to say that it is the most annoying, terrible problem that we face as an IM industry today.

Admins are just basically crushed under the, you know, the, the, the burden of having to manage the cross product of entitlements between end users and m applications. But it's all not all bad news. There is some good news over the last three years, we've actually made more progress than the previous 15 on this problem. And as usual, it's led by, you know, the large technology vendors. So everybody in this room was likely heard about Google's Zanzibar paper.

This is how you know, the paper in which they've described how they build access control for Google Drive and Google Docs and you know, the rest of the Google franchise. And of course a lot of these other tech vendors followed suits. Some of them emulated the Zanzibar model. Some of them have a more attribute or OPA based approach. But you know, these, these folks are big enough to go build their own in-house solutions. There's a lot to learn from them. The bad news is that we've basically got a little bit of a technological mess in our hands.

We used to have a simple model, you know, r a and a simple protocol ldap, and now we have just a cacophony of three letter or four letter or five level, five level acronyms. And it's very, very difficult to sort out a bunch of different models, enforcement points, implementations and so on. Not to mention vendors. It used to be back when I was working at the, the Evil Empire, Microsoft, we had 95% market share. And then the rest kind of did, you know, an LDAP thing. Now we have a ton of vendors, each one basically having a somewhat different point of view on the problem.

So even though I talked about this being the number one problem, at least in my humble opinion, that we have to fix as an identity and access industry, the market's frozen. There's so much noise in the market both from a technology standpoint and a vendor standpoint that it's very hard to go figure out to do. And so that is really what this talk is meant to address. Let's jump in, let's actually talk, break down all of the technology that we have at our disposal and then talk about the vendors and their points of view.

So drilling into technology, we would say that modern authorization boils down to five principles. And you know, there are, you know, three of these that are called the big three. And I'll contrast the old way of doing things, which is, you know, now considered anti-patterns and the new way of doing things. So first of all, in the old school way of doing things, each service or application of course data's own authorization.

And the modern practice is to basically build a purpose-built authorization service like Google did with Zanzibar so that you don't have, you know, authorization done in end places. You have it done in one place. Of course not everybody is Google and you can't all afford to go build one of these things. So fortunately we have a set of open source on, you know, that, that we can use to, to go build on top or a set of vendors that provide some of this. The second one is, the second anti-pattern is using coarse grained roles, you know, that are baked into applications.

And the modern approach here is fine grained authorization, fine grained access control. That really enables a very important security principle, which is the principle of release privilege. This is the idea of giving people just enough permissions, but no more than the amount of permissions that they need to get their job done. The third antipater is basically writing logic, authorization logic as if we're switch statements inside of the application or service. We call this authorization spaghetti code. And the best practice is to extract that code and express it in a domain-specific language.

We call that policy-based access control. And that enables another important principle, which is separation of duties. You have the application developers building the application, and they don't have to worry about the access control logic because the security team can actually own and evolve that. The fourth anti-pattern is baking scopes into access tokens and treating them as permissions. This is essentially a, a, a security bad practice considerate at this point because as soon as that access token is minted, it's already outta date.

And of course the modern best practice is realtime access control. Some people call this dynamic, some people call this just in time. Some people call this runtime, but it's all the same thing. It's the idea of every time you're about to go access a protected resource, you make a call to the authorization system with a user context, the permission, the resource context, and get an answer as to whether this user has this permission on this resource. And then lastly, most people have login trails. Almost no applications today produce artifacts around decisions.

And the best practice is comprehensive decisions captured centrally for compliance and for forensics. So let's jump into what I call the big three, which are fine grained policy-based, real-time starting with fine grained access control. Now it turns out that there are two ecosystems that are emerging here.

What I, the first one is what I call the policy is CODEcamp evolved around opa. Now OPA is kind of the air apparent to exact, forgive me Jerry for saying this, but it it, it looks like OPA is essentially taken the, you know, the mantle here. It's based rooted in a attribute based access control type of, you know, methodology. And there is a lot to, like, here it is a essentially a, a graduated project from the cncf. This is the closest thing we have to a standards body in the cloud native world. There's a single open source implementation.

It's a very general purpose flexible decision engine and it's, it seems like it's tailor made for policy-based access management and aac. Now there are also some minuses. OPA comes in with basically a, a, a simplified language. It's not angle brackets, but it still has a pretty steep learning curve. Unlike what Gustav said. I would say that most developers that come in and they're trying to evaluate some things, I would say that they have to learn enough about OPA to even get started.

So, you know, it's not a linear learning curve, it's a step function learning curve. The second thing is that OPA has no opinions. It's very general purpose. So you kind of have to build from first principles. It's like building an assembler basically. And then the last one is that OPA has a policy plan, it has a great policy story, but it doesn't have a data plane. It doesn't have a data story. So you have to bring data to the engine. The Zanzibar world is the policy, is data, you know, kind of world. And I would say that this is, you know, has almost the opposite strengths and weaknesses.

So it is where OPA has no opinions, it is a very opinionated model. And the idea is that you can model relationships between the objects and subjects and that's how authorization rules are built. If you've ever used Google Docs, you know what a document is and what a, you know, folder is and creating viewers and editors and commenters and owners that's basically building a graph. And the process of authorization is walking that graph and figuring out whether there's an ed, a set of edges on that graph that carries a permission.

So very opinionated model and it's actually great for a surprising number of use cases. Now the minuses are Google didn't open source anything, they didn't even write a spec. They basically wrote a technical report. So you have at least half a dozen vendors that you know, each has built this, the, the, the i, you know, these ideas a little differently. No common schema languages, no common data languages. And it is a little bit hard to go outside of the strict reback model. Not impossible but hard. Fortunately.

Now we have, you know, a third kind of philosophy coming in, which is, hey, let's get the best of both worlds Topaz, which ATO sponsors is one such project. We've basically taken OPA as a decision engine, Zanzibar as a data model brought them together. The second of the big three I want talk about is policy-based access management. There's a lot of confusion here that thinks that basically p a m is the same exact thing as attribute based access control, but that doesn't have to be true.

The basic idea is that you're extracting the authorization, authorization logic out of the application and expressing it in a domain specific language outside of the application. That is the core idea. Now on the left here I have an OPA policy that is, you know, an ABAC policy, although it has an Easter egg in there where you have a little bit of a reback, you know, you basically can, you know, are allowed if you are the manager of the user that you know is, is logged in and you know, so you can combine these styles here.

But the idea is that P A M P policy based is not exclusive to attribute based access control. You can have a policy-based system that is RBACK or a a or reback, but what that gives you is it simplifies your logic. Here I have a no JS application that you know, or a, a route handler that basically fires on the API user's route. All I have to do is insert this piece of middleware check oz and it'll do the heavy lifting of calling the authorizer, passing in a a resource context and a user context and getting back an answer. So no more if switch statements, no more spaghetti logic.

What that gives us is the ability to store inversion policies as just like application artifacts with a get change log under the control of the security team. The third one of the big three is real time. So we think that done correctly authorization is, is a distributed systems problem and explain why authorization has to happen locally. You can't take a 50 or a hundred millisecond network ramp trip in the critical path of every application request if you're doing runtime or realtime authorization. So the authorizer has to be deployed close to your application.

So it gives you a small number of milliseconds of latency and a hundred percent availability. And it wants to compute decisions based on cash data because again, you don't want to go out to another system to go bring in all this information and then compute a decision, but you want that decision to be computed over fresh data. So what you really want is a control plane that mediates all of the data changes and fans them out to your authorizers. So for example, user information identities come from an identity provider.

That's what the source of truth and you want them any, any change you want farmed out to all the edge authorizers that are listening. Likewise, policies are stored inversion in a policy in a source control system and then delivered to the edge authorizers. And last lead decision logs need to be gathered from the edge and centralized in your logging system, your seam tool. So now that we've gone through all the technology, let's talk about vendors. Now I am not an Analyst, but I do play one on TV and I have a little prop for it even.

I'm gonna get into the proper attire at least for the next three minutes. And you know, another disclaimer here, you know, this is best effort research. We're talking about, you know, a set of vendors here. If we're wrong, if I'm wrong here, please come find me later and we will correct that for a future presentation. And lastly, there are no right or wrong answers here. This is basically just a meant to be a a vendor map, a market map to help kind of, you know, sort through the maze of all what all these folks do because all of them use the same words, fine grain, policy based, real time.

So let's talk about a few axes. The first one, the first dimension I want to talk about is what I call it centric versus dev centric. Now this is really about whether, you know, the vendor is trying to sell to the entire organization and the buyer happens to be a central org, like an IT org that wants to solve this problem for the entire organization or whether the vendor is trying to sell into an application, you know, into the VP of engineering, into basically the developer side of the house right now.

That's not to say that, you know, if you're a top-down type of vendor, you have to get have a a solution the developers will adopt. Otherwise, you know, what's the point? And likewise, if you're selling into engineering, you have to have buy-in from all the stakeholders. But the folks that sell top down are on this column. And then I have another, you know, dimension, let's call it a fine grained, you know, kind of set of criteria here for developers. And I use a a, a terminology that we used to use a Microsoft a long time ago.

More is, think of it as a visual basic developer, Elvis, think of it as a C sharp developer Einstein, think of as a c plus plus developer. And so here we have permit, which I believe Gustav mentioned, they focus on the folks that basically they use things, words like low-code or no-code. They're trying to simplify, they're trying to extract, you know, all of the coding out completely. The middle ve in the middle column are the folks that are trying to find some balance between making the, you know, easy things simple and the the harder things possible.

So, you know, have some opinions here but also have enough flexibility to accommodate more interesting and more complex use cases. And then the last column are folks who really build powerful toolkits that you know, you need to be a, a pretty solid developer to put together. But these are very powerful tools. And then I put styro in the middle because even though they sell top down a lot of orgs find themselves using opa, bottom up developers bring it in. The next dimension I want to talk about is model.

So starting with the, what I call a REBACK plus model, multi-tenant re rback or sorry, rback plus model permit again is you know, tries to aim at the simple side of the house. That's not to say you can't do AAC with permit, you can, but they aim for an rback oriented model. The next column here are folks that are aback oriented. Servos cloud entity started with opa. So their aback plane ID started with exactl. So their avac and styre of course is the the parent of opa. The next column is, sorry about the formatting here, what I call a graph oriented model. Reback model.

The first four vendors have built what they call are Zanzibar open source implementations. So they specifically try to build reback and then the last two, they never used terms like Reback or Zanzibar, but they have a graph model under underlying them. And so they're graph oriented. And then the last column I would say are hybrid vendors. So for example, AER has built something that unifies avac and Reback so has scaled access. It started from opa, it brought in a graph model and also predates the Zanzibar paper.

Again, a flexible hybrid model. And the last one, I have actually 10 of these, but I only have time for for one more a cor gram. So proprietary versus open source. This is not to say that you know, on the left side these vendors often use open source but they don't choose to open their core asset. The the core authorizer on the right side you have a set of vendors that have an open core model.

So they've open sourced their, their engine, their authorization engine and then I put permit somewhere in the middle again because even though they build on OPA and they've open sourced their control plane opal, they've not open sourced their core authorizer. So AER the big three, you know, we strongly believe in fine grained policy-based real time and of course we believe that authorization is a distributed systems problem. So authorize locally but managed centrally. So hence a distributed control plane. And we are developer centric.

So authorization with a single line of code, we integrate with everything you have and we strongly believe that the core authorizer needs to be open. So we're built on a cloud native and open foundation. That's all I have. I do want to talk about a panel that's coming up with a few of these vendors. Tyra's gonna be, their signal's gonna be their A sort is gonna be represented by Gert. Please hear about them, ding out the, you know, kind of the, the pluses and minuses of the different models. And come visit us at booth 44 if you wanna see a demo or talk more. Super thanks honor. Thank You.

We have one question now, given that you said that opera is missing the data plane, the question is this, how would the modern way of authorization contribute to the zero trust model? So I would say in all of the ways that I talked about, so I would venture to say that you can't really get to a zero trust model without modern authorization. Fine grained is a must have. Why principle of least privilege. You won't get it with Rach, you won't get it with course grained roles and separation of duties. Another very important principle, you won't get it without policy based, right?

Comprehensive monitoring, you know, you have to do that through real time access control. And then of course, you know, being able to gather all the fine grain decision logs, that's a, you know, that, that, that has to be part of your, your, your monitoring story as well. So I would say you can't really have zero trust without doing modern authorization. Super. Thanks so much. Thank you. Clap.