KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Optimize your decision-making process with the most comprehensive and up-to-date market data available.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Configure your individual requirements to discover the ideal solution for your business.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
Join this discussion about the efforts of the AuthZEN working group in the Open ID Foundation, which will include an overview of the authorization space, and the various technologies and players involved. The panel will also discuss why the group exists, the problems that it is trying to solve, and the state of the current work.
As Authorization appears to be the next horizon for standardization efforts, and the multiple technologies, often incompatible with each other, the need for standardization becomes more and more crucial. Come and hear how XACML, Cedar, Graph, IDQL, and more.
Join this discussion about the efforts of the AuthZEN working group in the Open ID Foundation, which will include an overview of the authorization space, and the various technologies and players involved. The panel will also discuss why the group exists, the problems that it is trying to solve, and the state of the current work.
As Authorization appears to be the next horizon for standardization efforts, and the multiple technologies, often incompatible with each other, the need for standardization becomes more and more crucial. Come and hear how XACML, Cedar, Graph, IDQL, and more.
Alright, so who wasn't here for the introductions of any of these guys? No, actually I think we will just do a roundup for, particularly for anybody watching online. Eve Mailer, founder of consultancy, ven factory, member of the Zen Working Group, and Lover of all Things permissions. We're on these now. Okay. Adam Ross Bridge, product manager for Ping's authorization product line. David Beard, CTO at Amatic, Alex eu, CT at Three Edges Graph Guy. I wonder if this works. Alan Foster, one of the original founders of For Truck 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 gonna be talking about why authorization standardization is imperative. Now. There was a, a session yesterday talking specifically about Auth Zen. Who here was at that panel by the way? Yesterday? Wow.
Oh, guess you're all all here for V two. You Had to. Awesome. We'll try and talk about different things this time. Some of you're on that panel. So the first question that I wanna pose is when it comes to, I guess I'm gonna call it pbam, that doesn't sound right to me, but p 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, there is a piece around, you know, creating the, the OIDC, the SAML of authorization, right? Which can help adoption. But when I've spoken to some customers about the standardization challenges, it's 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, to effectively pick a path through, through the patents here, 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, the engineering community, right? But in terms of this being something that's long, 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 I've heard vendor locking as also people don't want to do that. So having a a 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, I'll add as well that standards can help us bring patterns, design patterns, so that when your development team or your architects wanna do externalized author authorization, so number one, they, they need to have the education material. But number two, it's 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 pet, PDPP star P architecture? So having that comfort that others have thought about it and put together design patterns and, and standards and, and interactions.
That's, that's, yeah, increased success. I'm gonna go in from a different track altogether. Nice.
That is, I don't think it has anything to do with the protocols or anything else at, 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, in the 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, so like why now? Is the pain actually greater now? What is the source of the pain there?
So yes, there the, the pain is greater and we like people to suffer. I'm kidding. Scratch that. Wow.
No, but the, the pain is greater but's, it's probably 'cause there, 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 will comment on that. But authentication is sort of more mature, although it's still broken. Yeah.
I Mean, so that gives people bandwidth to work on authorization. Yeah.
I I think, yeah, authentication is solved, a solved problem apparently with sies 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, an awareness that has grown because of that. There's not a week that passes the, the 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, you know, cloud native architectures with like 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, 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, Right? 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 a PR gateways wonder of wonders, we've got a web server, right?
We, we've got a point that we can intercept the request, we can do some stuff in the, 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.
So, but it's right there in the zero trust architecture and, 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, 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 Zen 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, 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. 14 implementations total that now conform to that standard. Going back to your point, Alan, and your point Adam Adam's too, Adam.
Yeah, I know. Yeah, Yeah.
I, I, I feel left out Anyway, but the, the call to Action change, your names Avid, Avid. We, now that we have these 12 vendors slash frameworks, we gotta go out to the EPI gateways and tell them, Hey guys, you implement all the Zen because it means for you, you know, you Axway, you zulo, you, whoever, you may have a one-off integration with Ping or with axiomatic.
Well, if you do all the Zen, you're gonna get all the vendors for free. So that's gonna be a really great next call to action.
Just, Just think that there's not only one choke point, though. There's like microservices show that you can have a lot of shock points, actually. Yeah. And that's something we'll have to be cognizant of, I think. Yeah. In the development as we go.
Now, there, 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, as we've seen, there's a lot of things that happen in, in many environments.
So there, there needs to be a way to communicate events in real time. Because what is true now may not be true, you know, in a few seconds from now. And so this particular important, if you, if you're using authorization at the time of authentication and you stuffed your access token with a bunch of things, how do you invalidate that? So I think that's kind of the, the mission, the first mission that they were going after with shared signals that in signaling security issues, I, I think there's a desire to make authorization more real time, right?
Do you know, and to, to fold in real time information across the estate, right? And there are different ways in which that can be accomplished, like in different, in, in different implementations, right? So some implementations can reach out and pull signals back. What we're talking about with CAPE and Risk and SF is a way of eventing, right? So sending those signals and that, that data around, right? So overall, what that means is that we just have better sources of more current information. And that eve goes to the second part of Zen, which is design patterns, right?
Because there's really two models, at least two models in authorization. There's the P star P, so PET PDP is what Alex and Adam presented in, 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 cap and risks come in because they can be used to restrict a token that has been issued or augment, you know, it could, it goes either way, right? Augmented 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 'cause we haven't done this work yet in Zen, 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 risk and cap events, why not an authorization event? I Know you heard it here first and I heard it here first.
Okay, awesome. And we're doing an OAuth author Zen 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 gonna take the third one on. Cool. 'cause the third one is the big elephant in the room, uhoh, right? The the third thing we want to be able to get to is some way, and it, 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 gonna enforce policy, right?
Which is, you know, I don't know, Rosetta Stone or something, but some way of being able to express that policy and cough Ai cough. Well it could be cough ai. I'm thinking back to an xk CD thing about 14 standards. That's right. Standard that brings all of them together. Yeah. And now we've got 15. And I don't think that that's the right way to do it, but we do have, wouldn't it be great if we could have a single expressed policy that we can say Salesforce, this is our enterprise property, 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 gonna be really, really hard. Right? But that would be, that was sort of one of the things we spoke about upfront. It would be nice to, Is it in scope for Zen currently? Is it in scope for anybody?
Yeah, But it's not the We'll get there. It's on, it's, it's what we call the back burner scope. That's right. Yeah. Yeah. We'll get there I think. I think there's a, a couple of wonderful opportunities.
You know, so, so you know, a group of vendors have come together, right? We're working on that standard that 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? Yeah. Do you know authorization is a huge space and there's a whole load of different kind of sub-domains as part of that. And I don't think, do you know, even amongst ourselves, yeah, I don't think we have a shared view of that yet.
But If you started the A glossary, right? Didn't you, like you had this project I sort of, yeah, I did a sort of compendium.
I, I guess I should get back to that. I was gonna sign it in a graph. Now I wanna build what you said, Adam, and, and what you did in your presentation. We also need leave our little I am bubble or authorization bubble and go to the industry standards as you did in PSD two, PSD three, you know, and meet the people where they live and tell them, Hey, if you wanna express authorization concerns, here are the different languages that you can use.
You know, alpha or C 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 strength and weaknesses, all of all of them, right? Yeah. So apologizing to any online audience we might have right now, I'm wondering if folks in the, 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. 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 reasons Or, or what is it for? Shout it out and we'll repeat it. Both For what? Both. Both. Both. Okay. Efficiency, all right. Yeah.
And, And standardization. So regularizing everything internally, Consistency across the estate. Yeah. Yep. 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, what should they be thinking about and doing? Getting involved. Yeah. Get come into the, one of the, one of, I know the fourth work stream that we have in Orthon 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 is one, is he wants one way of enforcing authorization across 150 apps, but there are other ones, right?
And we are putting together a document now that says if we're going to standardize, what are the things we are gonna wanna have in that and, you know, come in and get involved in that group. It, 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 Open ID foundation, it's the working group called Zen. We do have one question that came in through the app, and I wanna, before we close, give a chance, I love this.
How will we force COT solutions, Zscaler Salesforce to use standard authorization or even enable consumption of external authorization tools? That's Very good question, isn't it?
Can we, we don't, Can we torture The answer? The official answer is sigh. That's Very true. Right? We don't. You do. Yeah. Yeah. The way that we force them is with our, 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 open, ID connect into their authentication, not because it, 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 is you express that it's important to you.
They're gonna have to meet that market need. What do we think? Are we at that point where people are gonna start enterprise are gonna start demanding this?
Ah, All right. Our work is cut up or a nice answer. Thanks the Circle of life that's, I'll give people a chance to have a final lightning answer on anything they care to comment on. Well I'll, I'll just add to that previous point, right?
Which, which I actually, you know, agree with that very much, right? But I do think that the, the COTS vendors are gonna need like 60% of their customer base, whatever that might be, right? 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 gonna be a long journey, right? Yep. It's a long journey and it's one that we've already started down. Yes.
Because I mean you look at a, a standard like Skim was actually the first attempt at trying to take users and group kind of information and populated it out into the SaaS app so they know it's already there. Skim 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, and Skim and OAuth might actually be way stopgap approaches to externalized authorization.
If you can provision entitlements to your SaaS apps, it may be just about good enough to achieve what you wanna achieve, which is both good and bad. It's good because you get better security, it's bad 'cause it might delay adoption. Dave Birch has talked about this as like, you know, the sailing, 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. Yep.
Alright, well I'm gonna close this here. I invite you all to engage, engage with us while we're still here and engage with the Zen working group. Yeah. Last point. We have a hackathon slash workshop slash whatever you wanna call it tomorrow from nine to 11 in C four, which Is upstairs.
Yeah, actually that's a good point. If you want to see it, see the very first draft version of Zen Real Life come tomorrow, bring your laptops and you know, we can, Yeah. And I predict that next year pack together there's gonna 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, the interop, the ability to change decision change decision providers, PDPs in the middle of your operations, create something using, I know you guys and then edit something using a completely different PDP and having that experience keep going is actually quite eyeopening. So come out, I mean it's, it's well worth looking at. You can See the power of external authorization in real life. It's really cool.
Alright, well thank you all. Hope you have a good evening and hope you have a good final day of UIC. Thanks for joining us.