Panel | OpenID AuthZEN: Standards for Modern Authorization

Okay, everyone. Thank you. So now we have our panel, and I'm going to hand this over to, into the capable hands of Eve, and you'll be in charge of keeping these people in order and making them answer all the questions. Okay? Right. Take it away. Sounds good. Thank you so much, Paul.

Yeah, I'm sort of stepping in to herd these particular cats. And I feel like Alex and David, you should stand up for a second. They're illustrating permit and deny in local fashion. So I'm Eve Maler. I'm founder of Consultancy Venn Factory, and I'm a member of the AuthZEN working group, and we'll be focusing quite a bit on that today, and I'll just invite each one of you to introduce yourselves.

Hi, I'm Gert Drapers, founder of Aserto, part of the AuthZEN community as well. Before that, Active Directory, Azure AD, and some other startups, but that's it.

Hi, Alex Babineau, CTO at Three Edges, generally the graph guy in the room. Hi, I'm David, CTO at Axiomatix, generally the policy guy in the room, and part of Axiomatix had the pleasure to work for Ian at Salesforce.

Oh, yeah, that happened. Yeah. Let's see. All right. In this context, I'm still Ian Glazer.

However, the reason why I'm here is long-time authorizationalist. Went to the first AuthZEN board meeting, which actually qualified me for a panel. I have no idea. And OpenID Foundation board member. So he basically wandered off the street and found his people.

Well, I'm glad you're all here today. You've just heard another talk about some of the benefits of externalizing authorization, and Servos is also at the AuthZEN table, and so all of us, except Ian, have been working together to kind of bring a modern sensibility to authorization and bring some of the recent insights to light. And so I kind of want to ask you all, why are we talking about modern authorization now?

Like, you know, we have some older artifacts from 20-something years ago that had some of the same patterns. So what's changed? What's new?

For me, from my perspective, one of the things is, and I just have to comment, I do have minions and spies in the AuthZEN working here, but just not there myself. And the controls available to us have expanded greatly. And both of those things are happening, feeling like geometric progression, right? And so now, more than ever, getting our arms around the mess we need to actually express policy around has gotten more difficult.

And so I think we've hit a sort of wall that says classical tooling for things like RBAC and identity governance and administration don't work at these kinds of scales or with this kind of nuance, right? I want to understand context. I want to understand environmental state. And so these things are all seemingly happening at the same time. And it's sort of created this condition under which it's almost an inevitability, right? We have to do something different. And that's why we're seeing this renewed interest, I think.

Yeah, to sum it up, more data, more users, more services, more expectation, more regulation. You've got to handle authorization. You can't put it off anymore. Plus the fact that we've been dealing with authentication for the past 10 plus years, and we're finally getting to a point of maturity, hopefully, that is going to free up some time for people to focus on authorization.

Yeah, and also the use cases are so varied that I don't think, I mean, we don't think there will be a one-size-fits-all for authorization. And so we needed a way for all these systems to communicate with each other. And I think that's where ODSEN comes into play. We'll try to work on a protocol and a set of recommendations for all these systems to communicate with each other, including existing apps or even one-day, off-the-shelf applications. Salesforce, you can dream. We'll talk about that, too. You can dream.

So I think to summarize it, it's like we're trying to achieve our open ID, OS moment in authorization. All right. So we can make this finally pluggable. So hopefully there is some transparency between implementations. Why is that important? Because as I said before, it's like there are various use cases, and there's no one-size-fits-all. But hopefully from an application integration or service integration point of view, that allows it to make more traction and solve more problems. Okay. So that's a really interesting analogy.

It's one that the ODSEN working group members, I think, aspire to generally. It's interesting to me because authentication seems to have been somewhat readily made into a shared service. Can you talk about the challenges in making authorization into a kind of a shared service? What are the barriers that we're having to overcome? So I think one big difference is, as the previous presenter also pointed out, authorization is a data management problem, a distributed data management problem. You need to have facts to make decisions. This makes it a high transactional distributed problem.

That's different than providing a token based on some qualifications that you hold on to for a while. Also, we all speak different languages around here, right? You're Dutch.

I mean, I myself don't speak my language visual. These guys have languages, right? So how are we going to interoperate and exchange policies and decisions and things? So some use cases are very graphy. Some others are more policy. We should enable all of them, not just focus on one of them. So that's definitely a challenge. So you're saying that your thing is ancient Egypt and hieroglyphics? Talking about modern.

I think, yeah, to Gert's point, sometimes I'll compare authorization to like a game of musical chairs and you're not fast enough and you landed in between two chairs. Because on the one hand, you have the identity centric stuff and the identity that can be owned by a central IAM team. And it's quite clear and everyone agrees more or less on the schema of things in LDAP or schema or whatever. But the other chair is the application side, right? The distributed data problem and getting app owners to agree to what the model should be.

And writing policies or writing a graph, you know, configuration, doesn't matter what it is, in a consistent way. That's the hard bit. Okay. There's a couple things pointed out there where we've got higher mountains to climb, but we're climbing them, I think.

Now, a lot of people were inspired by Google Zanzibar paper. And Google has seen benefits from a new kind of approach and there's some other kind of SaaS companies. What are they, how is that affecting the landscape?

You know, Zanzibar is just sort of on everybody's lips. I'll go first. I think it was an eye opener. So I come from an ABAC slash policy background. So between 2010, 2020, it was like ABAC, ABAC, ABAC, policy, MAC, MAC, MAC, MAC, MAC. And we kind of forgot DAC in the process. And fortunately, Zanzibar came along and said, well, hang on a minute. It's not all about policy and mandatory access control. It's also discretionary access control and access control at scale. So that was an eye opener and it's certainly changed how I look at authorization.

Yeah, now Zanzibar is an interesting one in terms of graphs because they use tuples, which is actually little strings made of three elements, you know, node one, relationship node two. This is strangely reminiscent of a standard that was written back in 1997 called RDF, which was meant to describe the World Wide Web. Those were called triples back then and there are triple stores that exist to this day that are defining graphs. But what I'm talking about myself when I talk about graphs is labeled property graphs, which are quite different and much faster.

Now, in a triple store or a tuple store like Zanzibar-based stores, if you want to parse a relationship like, say, 10 hops, you have to do 10 IOs, basically. You have to find all these 10 tuples. Whereas in my world, it's just one IO. I find a pattern and I match it and graph databases are very good at that. So that's a very kind of a different thing. So other than that, Zanzibar is kind of logically, semantically similar. It's a graph and you look for a path, essentially. But in the back end, you're really manipulating tuples.

I think from a bit of a meta-observation perspective, so Zanzibar, now Cedar, others are starting to prove that the heterogeneity of the environments that we actually manage do require different kinds of approaches and that some of the things that's really interesting to me is that we see all of this innovation happening in different kinds of parts of the problem space. It's not just about the dominance of Zacamo or lack thereof. It's not about singular patterns. It's saying, hey, there's a whole robust world around policy problems, governance, management, creation.

There's a robust world about different kinds of substrates I want to manage differently. So the fact that we see things like Zanzibar and Cedar and others and Cape and what have you is evidence that says this isn't a homogeneous world and that the problem space won't lend itself to a single flavor. And that's actually really exciting. So basically the generativity of this kind of current moment that we're in is exciting because it's solving more of the problem space that maybe was hidden in there.

Well, yes. Because I think what you're pointing out, Zanzibar is a policy as data approach where there is Zacamo, which started the policy as code approach. OPA is a policy as code approach. We started with OPA. Our first observation was when we encountered a real customer is that we need data. And you need to bring the data to the enforcement point. And that's how we started marrying both of these systems, an ABAC and a REBAC system.

And, yes, it's very similar to graphs. I don't think that's wrong. And it's a slightly different approach. But what I found is that from a customer point of view, it's easier to mince their mental model from an RBAC model to a REBAC model because RBAC is really a subset. But it's managing it as data. But then they come to the intersection where it's like they say, I still need to make decisions on properties, either environmental or properties on an instance. So I don't think at the end of the day, as Ian said, there's so many applications and needs that there's no one-size-fits-all.

So, spoiler, AuthZen has initially at least defined a PDP-PEP interface. It's fairly simple, fairly easy to get your head around. But we've got, we had how many, 14 different implementations. Twelve. Fourteen? Let's do new ones. Two after the session.

No, no, no. Twelve companies. You guys did two and I did two. So a total of 14. Yeah.

Oh, I only counted myself once. I took the win. Notice that authorization is not arithmetic. I'll just point that out.

Yeah, obviously. Everyone involved. So obviously each one of those is going to have taken a different approach and provide different kind of pros and cons. So maybe from each of your perspectives, could you sort of describe, okay, interoperability is about strategically commoditizing the thing that isn't providing differentiated value. So share with all of us what you build sort of on top of that or with that kind of standardized AuthZen interface.

So the first focus is, as I said earlier, is trying to create our OAuth2 OpenID-like moments for authorization, which means standardizing an API of how to make effectively the decision call. I want to delegate. You make a decision for me. You give me an answer. What is behind that? How the policy is implemented? If that's policy of code, if it's a graph from Alex or it's like any other way, it doesn't really matter in that story. It unifies how an application talks to the enforcement. And that's the first step.

Getting to the point where it's like there is homogeneous or unified policy languages, I think that will be a far way out. It's like the IDQL is trying to do magic with regards to transformations and unifying things. But in a real-time environment, I think that is not. It's like from a processing point of view, that is viable, but not at a real time.

Yeah, I totally agree. Whatever policy language you use, just see the two sides of it. There's the management side, and it could be policy or it could be graph, and then there's the fuel of the engine. Whatever fuel your engine uses, whether it's Rego and Open Policy Agent or Cedar, as you said, Ian, or Alpha or Zappel, or maybe YAML, in the case of CERBOS, which isn't quite an authorization standard, but is good enough to configure their engine.

It doesn't really matter as long as you manage your policies in a way that gives you audit, access reviews, visibility, and transparency of that configuration. That's a huge point, which is the danger we have in identity is often we're obsessed with the how. And so going back to when we were talking about identity relationship management, people got obsessed with the how of implementation and not the outcomes that it was going to lead to. And so I think by getting a little bit... It's important from a protocol perspective to understand the how.

And different deployment models have different optimizations for different use cases. Having a clarity around the outcomes is the important point here, and then do we have appropriate coverage and context becomes the sort of next conversation. Then we get to a how. But it's often... It's been certainly in this space, like going back to the Zappel days, be like, let's start with the implementation. Let's sharpen those angle brackets. And then we get to the outcome. So we've got to think about that slightly differently.

I want to focus on something that we all assume, because we talked about the PEP, P-E-P pattern, and that's what we're standardizing. Just curious, in the room, who uses that pattern for authorization right now? Any show of hands?

I see two, three, four, five, five. Who augments their token at login time as a pattern? Any show of hands?

Come on, be honest. Come on, yeah. Who has hard-coded code in their apps for authorization? Anyone? Yeah?

Okay, more people. That's a winner. Who doesn't do authorization at all?

Yeah, who doesn't do authorization? All you other people. You need these t-shirts then, clearly. Is there a band of... If you haven't raised your hand, you should ask yourself some questions.

Wait, is it allow all? That's not cool. It's not cool? Oh. What we're talking about, pet-PEP is where we would like everybody to go to, because you need to authorize every single request in line with your trust. In particular, the pattern of authorizing at login time is probably not great, because whatever you stuff your token with might expire anytime soon, which is where KEB comes in, but that's kind of like a glue to a problem. That's kind of interesting.

Another work, this work that we're also doing is defining those design patterns and trying to provide some recommendations around those patterns. So we're getting close to the end here, and I want to do a little bit of a lightning round.

Ian, you're saying, well, don't over-rotate on the how, and it's really kind of like, what's the why? And I'd kind of love to hear from those of you who have implemented Authen, what is kind of like your top benefit or use case that you're seeing out of implementing it? I think it will aid the move towards externalizing authorization. As we see based on the hands, it's the winner still. I think that needs to change. Nobody's building their own authentication system anymore. They're relying on standards of how to do this. That's where we need to get to.

So externalize, manage your policy separately, use a standard API. Yeah, I think on that, and also maybe shift away from just using roles for everything. Roles have their place, but maybe we've got to think about 21st century ideas. Graph roles.

Not roles, just graphs. Relationships. So to echo what you said, and also what you said, Ian, I think two things. If I look at the history of authorization, 10, 15 years ago, when I was working in authorization, we did not talk to the competition. It was a very, I don't want to say aggressive, but very cold environment. It wasn't fun. It was the ankle brackets. It was the ankle brackets, definitely. I blame Eve.

But like today, one of the side effects of having done AuthZen is that we talk very openly between Cerdo and Serbos and Three Edges and Axiomatics, and many, the 12 vendors or the 12 frameworks, it's not all vendors, by the way. So that's cool. And then to go back to Ian and how and what, the other, like the call to action for us at AuthZen is to go to non-authorization vendors and say, hey guys, you should implement AuthZen.

And also to go to non-identity standards, go to FHIR, for instance, and HL7, so healthcare standards, or go to open banking and tell them, hey guys, there's a path to authorization. And then if you follow that path, I think one of the interesting outcomes is, and this may be just a spicy take on this, is you actually start to set yourself up to actually use generative AI and LLMs for good because you can now actually use them for translation processes in policy, which you couldn't really do when it was hard-coded in the world. And I think there's promise there. I'm not guaranteeing any outcome.

Your mileage may vary, consult your lawyer before deploying policy, but it opens up a very interesting kind of world that says can we have real innovation around policy, but we only get there by going down that path. Very cool. So I learned that curly braces are friendlier than angle brackets. One thing I think we need to share with the audience is like, okay, if they're interested to follow along with AuthZen or join or contribute, how do they do that?

Now, David, you're one of the co-chairs. We have like 17 co-chairs. I don't know how many. A lot. But the graph guy isn't one of them. You should be. Joke aside.

Yeah, go to openid.net slash WG slash AuthZen. That's A-U-T-H-Z-E-N. Or Zen. There we go. If you're... Say what? If you can spell. If I can spell it, yeah. Slash da-da-da-da-da-da. Thank you. Yep. So one other plug. So on Friday morning, 9 to 11, we're having an interop event. It's similar than the one that we actually did before. It'll be one week better than the one at Identiverse, so you'll want to see it. The demo still works. Right. We have time for maybe a question if there's something.

Yeah, Vlad. A quick question. I know the biggest difference in your authentication authorization is that nobody wants to own authentication, but application owners are really, really afraid that you take away their rights to say yes or no.

Okay, the application owner problem. As a human factor guy, question to you. How do you work with that? I have an answer. I spent 10 years in consulting before this, and I can tell you that developers... My experience, anyway. Developers hated doing security stuff. They just wanted to do their stuff, and security was the last thing that they wanted to actually have to work on. So I think they'll be quite happy, myself. Maybe I'm wrong. So that's a new insight for me, is just tell them it's icky security stuff, and we're going to just take care of it.

So from the ownership point of view, I think they're actually very happy that they get insight of how permissions are assigned. Because the inverse is also becoming true, is that it becomes discoverable. Based on the various mechanisms, one of the other things we have on the standards ballot is to be able to search from subjects to objects.

It's like, who does everybody have access to? How does this pass go the other way? The graph guys are an advantage there, of course, but the Zanzibar guys are not sitting on their hands. So a thing that you're hearing now is that it's not just going to the standardized interface for a very simple thing, it's added functionality that they get kind of for free if we do our job right. So we're building three APIs, three authorization APIs. The first one is the one we did at the interop last week and this Friday, like Gert said. So it's very much a yes-no question, single yes-no question.

The second one we're going to do very quickly is a batch yes-no. It's pretty much the same thing as the single one. And the third one is going to be the most interesting one. It's going to be what Signal and the tool call search, what I call reverse query, what some folks at OPA call partial evaluation. It's being able to ask it, what can happen? Or who can get access to resource X? Or what can Alice do?

Literally, you can make a policy out of what could possibly go wrong? And it's great, it's really powerful. Going from yes-no to who, when, why, where, how, basically.

Yeah, that's much more powerful. And it'll be interesting. And so if you have use cases for that, it's a perfect reason to get involved and contribute those. I'll wrap it up here. Thank you guys. Thank you to the moderators of the track. Thank you.