Panel | Why Authorization Standardization is Imperative

All right, so who wasn't here for the introductions of any of these guys? No, actually, I think we will just do a roundup, particularly for anybody watching online. Yves Mayler, founder of consultancy Venn Factory, member of the Auth Zen working group, and lover of all things permissions. Adam Rusbridge, product manager for Ping's authorization product line. David Brossard, CTO at Axiomatics. Alex Babeanu, CTO at 3Edges. I wonder if this works. Allan Foster, one of the original founders of Fordruck, and always been into authorization. That's fair. Did it work?

Yeah, I think so. Yeah, everybody, you know, loud, clear, bell-like tones. Great. So we're going to be talking about why authorization standardization is imperative.

Now, there was a session yesterday talking specifically about Auth Zen. Who here was at that panel, by the way, yesterday? Wow. You're all here for V2. You had to. Awesome. We'll try and talk about different things this time. Some of you were on that panel. So the first question that I want to pose is when it comes to, I guess I'm going to call it PBAM. That doesn't sound right to me, but policy-based access management. What exactly is holding us back, in your opinion? And I'll just ask each person in turn. Sure. Yeah. So I can go first, okay?

So there is a piece around, you know, creating the OIDC, the SAML of authorization, right, which can help adoption. But when I've spoken to some customers about the standardization challenges, for them, it's that we're forcing the customer to make a subjective decision, right? So we're actually putting a lot of responsibility onto the customer themselves, you know, to effectively pick a path through the patentee, right? There are different approaches at this point in time in terms of authorizations. There are different protocols.

And ultimately, you know, someone's having to make that business case internally about, you know, shifting from homegrown solutions to something externalized. And I think internally, there's a lot of benefits from the engineering community, right? But in terms of this being something that's long-lasted for the next 10 to 15 years, without a standard, right, it can be hard to make that case that this is the right horse to back. Yeah. I've heard vendor locking as also. People don't want to do that. So having standards will help, you know, avoid that fear, I guess, of being locked into a vendor.

So that will help us, you know, as well. Yeah. I'll add as well that standards can help us bring patterns, design patterns, so that when your development team or your architects want to do externalized authorizations, number one, they need to have the education material. But number two is kind of what you were saying, Adam. It's knowing that you're making the right decision in a way and that there's a standard to back you up and that there's people that have thought about what the externalizing authorization would look like.

You know, are we talking about tokens? Are we talking about P star P architecture? So having that comfort that others have thought about it and put together design patterns and standards and interactions, that's, yeah, increased success. I'm going to go in from a different track altogether.

That is, I don't think it has anything to do with the protocols or anything else at that level. We can solve that. The real problem is that authorization is costing enterprises millions of dollars because we've got X number of SaaS apps out there, and in order to configure those SaaS apps to have the appropriate authorizations, you need to have an expert in each and every one of them. And standardization means you can have one expert that can do authorization across multiple apps.

One of our stakeholders in the Orsen group said he has 150 different apps with different authorization models, different authorization interfaces, and that's ultimately where the standardization makes the enterprise win. So, I mean, it was bad before. Before we had all these SaaS apps, we had all these, you know, custom-developed in-house apps.

So, like, why now? Is the pain actually greater now? What is the source of the pain there?

So, yes, the pain is greater, and we like people to suffer. I'm kidding. Scratch that. Wow.

No, but the pain is greater. It's probably because there's more data, more users, more services, more apps, more systems. It's actually good news, right?

You know, 10, 20 years ago, you could not look at your medical record online. Today, you can do that, but it means that we have to have the right protections in place, and so we need more authorization.

And then, I'm sure someone won't comment on that, but authentication is sort of more mature, although it's still broken. So, that gives people bandwidth to work on authorization.

Yeah, I think, yeah, authentication is solved, a solved problem, apparently, with passkeys and everything, although there's still more data breaches these days than there was before. So, then people realize that.

So, they realize that they need to do something else. Maybe there's an awareness that has grown because of that. There's not a week that passes without a data breach, right?

So, something's going on, even though we solved authentication. I think the other piece is that our application architectures are changing, right?

So, now we have cloud-native architectures with APIs, and API gateways become a hook, an integration point, where we can make changes without having to change some of that application code, right? So, time to value can be much lower at that point, or we can kind of go further down the stack to data layer access controls, right?

So, the mechanisms by which we can integrate are changing, and you can see that by the way that some of those vendors are actually providing, you know, integration hooks and extension hooks, right? Which, again, is simplifying how, you know, a standard can be taken advantage of. I think that's a really important point, right, in that we've always said that standardization on authentication was possible because we had to go through the web server.

We sort of didn't care about the app behind it, but the web server had to handle the HTTP request, and now having the API gateways, wonder of wonders, we've got a web server, right? We've got a point that we can intercept the request, we can do some stuff in the authorization place, and sort of the one we've always spoken about is that with authorization, we've never had a choke point. We've never had somewhere where everything had to go through, and the API gateways, I think, are bringing that.

It's right there in the zero trust architecture, and actually in a lot of pictures for the last 20 years, it seems like we now have this opportunity to put that in place. You know, there was an old saying, and I have not found this evidence of this online, but I remember people saying, you know, don't develop security code, develop secure code, and that's the whole idea of externalizing anything and making it kind of a shared service. So thinking about the AuthZen opportunity now, what is really being standardized there, and what do we have the opportunity to standardize?

So the first thing we did is the request response protocol. So how you send an authorization request from a client, an app, a thing, to a policy decision point, whether it runs on policy or ACLs or graphs, it doesn't really matter. That's the first thing that we did. And we actually have 12 vendors slash frameworks, which is 14 implementations total that now conform to that standard. Going back to your point, Alan, and your point, Adam.

Adam, there's too many A's. I feel left out.

Anyway, but the call to action. Now that we have these 12 vendors slash frameworks, we've got to go out to the API gateways and tell them, hey, guys, you implement AuthZen because it means for you, Axway, you, Zuplo, you, whoever, you may have a one-off integration with Ping or with Axiomatics.

Well, if you do AuthZen, you're going to get all the vendors for free. So that's going to be a really great next call to action. Just saying there's not only one choke point, though. Like microservices show that you can have a lot of choke points, actually.

Yeah, and that's something we'll have to be cognizant of, I think, in the development as we go. Now there's some other standards, nascent standards in the mix, like shared signals, continuous access evaluation protocols. So how do you think those might play together? What are the opportunities there?

Yeah, sure. So as we've seen, there's a lot of things that happen in many environments. So there needs to be a way to communicate events in real time because what is true now may not be true a few seconds from now. And so this is particularly important if you're using authorization at the time of authentication and you've stuffed your access token with a bunch of things, how do you invalidate that? So I think that's kind of the first mission that they were going after with shared signals. That and signaling security issues. I think there's a desire to make authorization more real-time, right?

And to fold in real-time information across the estate, right? And there are different ways in which that can be accomplished, like in different implementations, right? So some implementations can reach out and pull signals back. What we're talking about with CAPE and RISC and SSF is a way of eventing, so sending those signals and that data around. So overall, what that means is that we just have better sources of more current information.

And that, Yves, goes to the second part of AuthZen, which is design patterns, right? Because there's really two models, at least two models in authorization. There's the P star P, so PEP PDP is what Alex and Adam presented in their presentation. But you also have the session-based or the token-based authorization models through OAuth. And OAuth is getting new profiles to do even more authorization within the limits of the session or the token. And this is where CAPE and RISC come in because they can be used to restrict a token that has been issued or augment. It goes either way, right?

The token and then it goes back to your point about making authorization more real-time. So this is maybe a little bit of asking you to use a crystal ball because we haven't done this work yet in AuthZen, but should we be looking to add profiles to shared signals in order to solve some of the OAuth plus P star P patterns? I actually did talk to them about adding even a third type of event for authorization, like you have RISC and CAPE events, why not an authorization event? You heard it here first. I heard it here first. Awesome.

And we're doing an OAuth, AuthZen profile of rich authorization requests. Right. So to bridge the authorization server in OAuth land with the authorization service in PDP land. Yeah. And then I'm going to take the third one on. Cool. Because the third one is the big elephant in the room. Uh-oh. Right.

The third thing we want to be able to get to is some way, and it's a hard problem, but some way for us to get to express our desired policy with all of the different apps that are going to enforce policy, which is, you know, I don't know, Rosetta Stone or something, but some way of being able to express that policy. Cough AI cough.

Well, it could be cough AI. I'm thinking back to an XKCD thing about 14 standards that brings all of them together, and now we've got 15. And I don't think that that's the right way to do it, but wouldn't it be great if we could have a single expressed policy that we can say Salesforce, this is our enterprise policy, enforce it in the way you feel, and Workday, here is our enterprise policy, enforce it in the way you should. Getting there is going to be really, really hard. But that was sort of one of the things we spoke about up front of would be nice to. Is it in scope for AuthZen currently?

Is it in scope for anybody? Yeah, but it's not the... It's what we call the backburner scope. That's right.

Yeah, we'll get there. I think there's a couple of wonderful opportunities.

So, you know, a group of vendors have come together, right? We're working on that standard, the interface in the first instance, but beyond that, that does open up the opportunity to come up with a common language around some of these different use cases. And I think we don't have that common language at this point in time, right?

You know, authorization is a huge space, and there's a whole load of different kind of subdomains as part of that. And I don't think, you know, even amongst ourselves, I don't think we have a shared view of that yet. But if you started a glossary, right, didn't you? Like you had this project.

Yeah, I did a sort of compendium. I guess I should get back to that. I'm going to sign it in a graph now. I want to build on what you said, Adam, and what you did in your presentation. We also need to leave our little IAM bubble or authorization bubble and go to the industry standards, as you did in PSD2, PSD3, you know, and meet the people where they live and tell them, hey, if you want to express authorization concerns, here are the different languages that you can use, you know, alpha or cedar or whatever it may be. Or graphs.

And it comes back to that point, right, at the very beginning, right, about making that subjective decision. You know, how much as vendors can we really help our community understand, like, which to adopt, where to apply different approaches, you know, the strengths and weaknesses of all of them. So apologizing to any online audience we might have right now, I'm wondering if folks in the local audience, if you can raise your hands if you represent an enterprise that is doing any form of externalized authorization now. Okay. Nice. That's the best result I think I've ever seen.

Of course, we've got our affinity group here. I have a second question. Yeah. Is it for efficiency or better security? Or what is it for? Shout it out and we'll repeat it. For what? Both. Both.

Okay, efficiency. All right. And standardization. So regularizing everything internally. Consistency across the estate. Yeah. That's good feedback. So what do we all think people should be doing if they want to increase their maturity, take part, contribute, what should they be thinking about and doing? Getting involved. Yeah. Coming to one of the, I don't know, the fourth work stream that we have in OSEN is building up use cases. Yes. What are the things that make sense for people who are going to be using the authorization service to be able to actually want to get out of it?

I know that Hutch's one is he wants one way of enforcing authorization across 150 apps, but there are other ones, right? And we're putting together a document now that says if we're going to standardize, what are the things we're going to want to have in that?

And, you know, come in and get involved in that group. It's not a deep technical group. It's looking for requirements. And you guys know that more than we do. You guys are having to do that every day. And this is at the OpenID Foundation. It's the working group called AuthZen. We do have one question that came in through the app, and I want to, before we close, give a chance. I love this. How will we force COTS solutions, Cscaler, Salesforce, et cetera, to use standard authorization or even enable consumption of external authorization tools? Very good question, isn't it? We don't.

Can we torture them? The official answer is sigh. Right. We don't. You do. Yeah. The way that we force them is with our pocketbooks and buying that service. And if the market wants it, and we did it.

I mean, you look at Salesforce. They put SAML and they put OpenID Connect into their authentication, not because we sat down with them or anybody else sat down with them, because the market was asking for it. Yeah. Right? And so that really is the point. If you express that it's important to you, they are going to have to meet that market need. What do we think? Are we at that point where people are going to start, enterprises are going to start demanding this? All right. Our work is cut out for us. Nice answer. The circle of life.

I'll give people a chance to have a final lightning answer on anything they care to comment on. Well, I'll just add to that previous point, which I actually agree with that very much. But I do think that the COTS vendors are going to need, like, 60% of their customer base, whatever that might be, to be asking for something. And I think that so, like, in order to get to that 60% customer base, we do need the standard. That standard needs to be adopted in custom apps first, right? And at that point, then we can go to the COTS applications, right? So it's going to be a long journey. Yeah.

It's a long journey, and it's one that we've already started down. Yes.

Because, I mean, you look at a standard like SCIM, was actually the first attempt at trying to take users and group kind of information and populate it out into the SAS app. So they know it's already there. SCIM is actually another kind of auxiliary standard or standard in the same orbit because, and it's seeing some generativity right now. It's got things being added to it suddenly after many years, which is kind of interesting. So maybe the time. That's another. And SCIM and OAuth might actually be top gap approaches to externalized authorization.

If you can provision entitlements to your SAS apps, it may be just about good enough to achieve what you want to achieve, which is both good and bad. It's good because you get better security. It's bad because it might delay adoption. Dave Birch has talked about this as like, you know, the sailing of the clipper ships that just sort of like, it's the incremental innovation that then gets overrun eventually by the disruptive innovation. So maybe it's a natural progression. Yeah. All right.

Well, I'm going to close this here. I invite you all to engage, engage with us while we're still here, and engage with the AuthZen working group. Yeah. Last point. We have a hackathon slash workshop slash whatever you want to call it tomorrow from 9 to 11 in C4.

Actually, that's a good point. If you want to see it, see the very first draft version of AuthZen in real life, come tomorrow, bring your laptops, and, you know, we can.

Yeah, and I predict that next year there's going to be a really amazing amount of progress in this area, and I can't wait to contribute to it and to see it.

And one of the things just that I spoke about this a little bit on Tuesday morning when we were talking about OIDF, having a look at the simple app that we have with the interop, the ability to change decision, change decision providers, PDPs in the middle of your operations, create something using, I don't know, you guys and then edit something using a completely different PDP and having that experience keep going is actually quite eye-opening. So come out.

I mean, it's well worth looking at. You can see the power of external authorization in real life. It's pretty cool. All right.

Well, thank you all. Hope you have a good evening, and hope you have a good final day of EIC. Thanks for joining us.