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.
In this panel, we will host professionals from multiple industries who extensively use policy engines in their day-to-day jobs. We will hear from the end user's perspective what made them choose a particular policy engine over others and what important lessons they learned.
We will try to focus on use cases over the basic engine functionality and provide an in-depth comparison that will help you identify the one that works best for you.
In this panel, we will host professionals from multiple industries who extensively use policy engines in their day-to-day jobs. We will hear from the end user's perspective what made them choose a particular policy engine over others and what important lessons they learned.
We will try to focus on use cases over the basic engine functionality and provide an in-depth comparison that will help you identify the one that works best for you.
Okay. But if you could, before you start moderating yourself, if you could just introduce yourselves and what would, what this is actually should be about policy engines, which is something that I've quite interested in. So let's see what you have to say. Thanks. Cool. Well good morning everyone. Good morning everyone. Is everyone still awake? Just about. Just about. Cool. Awesome. My name is David, I'm the CTO at Axiomatic. I've been in the authorization world forever, almost.
I used to be one of the editors of the Swell Standard and I'm now a co-chair of the of Zen Working Group under the Open ID Foundation. And with me today we have Patrick Parker.
Patrick, do you wanna introduce yourself? Sure. Nice to meet you. I'm Patrick Parker, I'm the CEO and Co-founder of Empower ID Authorization is my own personal favorite topic in the area of identity and I've been in the identity business since about 1999. So Old timer. Old timer, definitely.
Sid, do you wanna introduce yourself? Hi. Hi everyone. Is it working? Yeah.
So, hi, I'm Sid, big Indian named, don't worry. What I just remember Sid, I work for Schneider Electric. It's a French energy management company. I manage their customer experience platforms. My goal is personalization and through that I ended up in authorization and access management. We pulled them in. Alan. And I'm Alan Alan Foster, one of the original founders of For Rock. I've been involved in policy and David and I first met on the Zack Mo Standards Committee way, way, way back when.
And so looking at, and I'm, I'm gonna step back from Access Manage for a minute and just have a look at the general prospect of decision making within the enterprise is sort of one that's my little bug bear. Alright. And our main mission really collectively here and a few other folks in the audience as well, is to, to make authorization a reality.
You know, one thing if, if we look at IAM and and authorization, I've been at it for over 10 years. You've been at it for over 10 years and, and still hasn't gotten to that aha moment. It's really hard thing to crack.
So, you know, maybe starting with Alan, like what do you think it's been that way? Why, why policy engines and and authorization are are not there yet, and will we get there? It's been an interesting, interesting history getting here, right? So the first one is that you cannot really effectively work out what someone can do until you know who they are.
And so, logically authentication was the first part of the problem that we had to actually solve. We've now gotten to the point where we can actually hand a jot around between multiple providers, multiple solution providers, multiple vendors, and we also of agree as to who it is. And that's a, a pretty reasonable place for us to start looking at the discussion that says, okay, now that we can agree on who it is, can we agree on what they can do?
I think the sort of second piece that came on with that was that there's an awful lot of relatively simple problems to solve and you don't need complex engines to solve, can you open the office door? Right? And OAuth came in as a very well timed piece of technology that solved all of those bar token kinds of problems and others, but it really solved those bar token problems, which meant that the demand wasn't really a tidal wave coming over us, it was just that, that delta up at a top for the really complex decisions. I think that's sort of why it's taken time for us to get here. Thanks.
And Syd, you've been building customer experiences for Schneider. You kind of fell into authorization. How did that happen and what was the challenge? What is the challenge you're trying to solve? And you've also looked at different authorization approaches, policy graph, other ways of tackling it, OAuth as, as Alan said, what, what, what's your main takeaway? Sure.
I mean, my journey primarily started with personalization. So our goal is we wanna show the users the right information at the right time with the right context. We just wanted authorization to be a solved problem so that we just ask and it figure things out. That's where we, and and that was main objective for us.
We, we have so many different teams that don't want to learn all of these things. We wanna manage that for them so that they can focus on getting the right data and giving the right experience.
So that, that kind of triggered our whole journey where we wanna centralize and then externalize. In that externalize we, we went through different models. In the beginning we thought our data is so messy, let's try to keep data aside and bring an engine that can work with any messy data. So that's that. That took us halfway and, and then we said, you know what, if we don't clean it now, who will clean it? So then we pivoted to maybe policy as data makes sense, graphs make sense. And we started structuring it.
We see like the immediate need is still solved by hidden security, by obscurity implementation. So most of our legacy systems probably have a table where the query says user right equal to something and get the data. But we want to have this as an abstraction at every level. Like zero trust as a fancy thing.
But it, we would like it if that's a solved problem and we just focus on experience. Wouldn't That thanks, wouldn't that be nice?
Yeah, That's a great T-shirt for authorization. Would a solve problem? It just works. So we're moving to a model where we're just gonna ask people to do the right thing.
You know, we don't need authorization, just please don't look at other people's stuff. Can we trust you? I wanna bounce on something you said, Sid, you know, you wanted it to be easy and and understandable and developers not have to worry about that. So before I ask you the question, there's really two right now in authorization. There's two main camps, policy ask code or or authorization based on actual policies that you write. And then policy as data where you're relying on a system that has all the data and you can reason on the data, typically through a graph.
So that's the Alex's camp here. But going back to the policy side, you've been working on trying to make policy authoring super easy through LLMs and other techniques. Can you tell us a bit more about that? Sure. It was just a spike, but, but basically for this workshop, I took the off then standard information from the website, set it, vectorized it, set it in, and then designed the multi-agent, LLM where one was the, the data scrubber to ensure that you weren't trying to fool it. And then the other was the authorization engine that would implement the policies.
And it was, it actually proved very interesting, very accurate. And you could then, so by telling the agent that it was an expert in opa, Rigo C Alpha, it could accept inputs in various formats. It could output your policies in various formats. And you could even author the policies in natural language if you wanted to. So you could ask it almost any type of question, natural language question, ask them question and you could get the output in any format. So it's kind of rolling around in my brain the implications of that for our area. But there are a lot of, a lot of possibilities there.
And it also leads into explainable ai. 'cause that was a cool side effect was you could always ask it why it made a decision and it would give you an amazing answer about how it evaluated the policies and what, why it came to that conclusion. So transparency is gonna be much better. Thanks.
We, we had a bit of a chat. So two things. We actually did an interop again this morning from nine till 11. If you're interested in the notes, we can, we can share those notes. But Alan also had a bit of a chat with Martin Inger right before this session and Martin said something interesting. You really want to tackle authorization from the top down, starting with policy governance, starting with policy design, with authorization requirements, gathering, so and so forth, kind of what you were alluding to with LLM, but also the, the bottom up. So two questions, one, one for you Alan.
You know, what is Zen doing to address either direction? And then one question for you, Sid, what is the developer reaction to you trying to bring externalized authorization and how can you make it easier on the developer to adopt the technology so they don't fight it back? So Alan Zen.
Okay, so Let's start off with, with Zen, we realized very early on that we, it was stupid to try and boil the ocean. We couldn't solve all of the problems for all of the people all of the time. The other observation that we had is that the typical request response loop, the the is the, the is allowed question, right? Is this user allowed to do this under these conditions? And you get a response back, looked very similar regardless of who you were using it, it, they're sort of the same kind of question.
And so the, the, the fairly small step to get us all working together and say, well, let's come up with a standard API that we can all use to ask that question and get a response back involved weeks and weeks and weeks of arguing about whether there should be a comma here or not. But ultimately semi coin, ultimately we got down to a point where, yes, let's start down at that where we've already solved 90% of the problem and let's try and standardize that moving its way up. And I think that leads, that part of it leads very well into the next question with Sid.
The part up top, we sort of looked at it and it's like, don't go here. There's dragons up here. This is scary stuff. It's also much more longer term trying to get the, the policy definition, policy language compatibility up at that level. We'll get there eventually, but, but that's probably where the, the translation layer that you were talking about fits in quite nicely. Yeah. And I'd like to explore that some more soon. But yeah, that we went in at that sort of bottom level and saying, let's just get interop working.
And if you haven't seen the interop, one of the things about it that for me, and I've been around in the industry for a few years, it was actually quite mind blowing, seeing the, the result, the fact that you could choose which policy engine you were hooking up to and start doing some actions. We have a a to-do app, you can create a note, you can edit a note, et cetera.
So you choose your policy engine, you create a note and you then choose a different policy engine and carry on going and it's gonna enforce the same policy on the same object for the same user, but it's just going off to a different place to ask for it. From a developer's perspective, not having to make a decision to rely on any particular policy decision point while they're building their app is a, a freeing thing, right?
It's, it's like, if I can call this, it'll just work. And that I think leads nicely to how do you make them do that Abstracted? I mean when we attempted to bring this to developers, business analysts and everything, we struggled a lot by, we initially thought let's let's try to show the tools that are there in the market. Maybe that brings them some anchor point to make a decision on how things would work. Because most developers don't think about resources, subjects, actions. Like it's so, such a norm in the group, right?
So one of the questions that I typically got from a developer is, I can just query the table. Why are you making me learn all these things? How can you say that this is faster than a query? So I think one of the mistakes we made in the beginning was to say that this will give you better performance, which was not the main starting point. Performance should be a side effect, but I think the audit capabilities and not having to worry about it and having more security should be the primitive. And also we, we try to prioritize UI in the beginning because we thought it, it formed a better anchor.
So even for business analysts when we were talking about all these things, it was so much in the air. Even you guys discussing about o or two as a solve thing. I have many developers who don't know how o or two works. They just know that it is already solved. So they just focus on components and APIs behind the scene. There is a token. Someone validates it. Yeah. So I have to pick and coach very specific kind of developers. I still feel this vocabulary is very new, at least in the market that I'm, I'm running around.
It's like teaching a front-end developer to suddenly talk about deep AWS services. They can Google some things, but it's not going to make sense immediately. So education is still like your number one concern Yeah. In a way. And so hopefully having standards like Zen is gonna simplify your task because you could just point them to the documentation when it's written and we put the comma in the right place.
Yeah, I would like, I I I hope they, they would read it Pivoting slightly to the discussion around policy. I wanna focus in on one of the points that you just made. And that is, why can't I just make a call to this table and get the data back, right? The average developer thinks in terms of the 10 lines of code before and after where they're actually working. And so the idea of being able to do query if then else do their thing makes that decision. And it is an authorization decision, but it makes that decision only in the context of this one call.
And if we go to a policy engine, no, it's not faster, although maybe ultimately it will be, it's not faster, but it forces the developer to think about the bigger context of what is the context I'm making this decision, right? Where is it being made?
And so, and we've all been through the thing where you're building an app and we are told only admins should have access to the admin page and everything's going great. And then a week before shipping, someone comes in and says, oh, only admins and the executives, now we know the executives should not be on the admin page, but they want to be able to see it. So add the executives to that. And the impact of that is 500 call sites where you're making the query now have to go in and have an and clause put into it, which invariably we're gonna get half of them wrong.
And, and that adds in the break. Whereas in a policy you can go in and say once and executives and gets that piece. So it gives some consistency and coherence where I think the real value of running on policy comes from And the transparency and the visibility and the auditability. I mean these are all benefits of decoupling your authorization and, and yesterday's presentation, Adam Redbridge who's the, the PM for authorization at Ping Identity, he gave us some interesting numbers.
I don't remember exactly, but I think it was along the lines of if you do externalized authorization, then your dev time is gonna go down by 60% or, or the cost of doing authorization goes down by 60%. 'cause you don't have to have spaghetti code within, within the app. And that's, that's huge. Way back when Oracle had a statistic that said 20% of a developer's time goes to authorization. So if we can save that, then all the better. So it's not just the auditability, it's also saving time.
But one thing about the question, the original question, why haven't we solved this is authorization is this big term is a term that encompasses many different use cases like we were just discussing. So in one case, authorization is, well, which data, which rows should I be able to see? That's a very, they might, that's a very different question than which user interface elements should I be able to have from a user experience perspective. And then that's a different question from, can I perform this bank transaction given this dollar value in this context?
So it's all authorization, but there's a very maybe hopefully wrapped in the same standard, but very different approaches or different use cases to try to achieve that. And the data one's very hard. Yeah. Thanks. We've got a couple minutes left. Do we wanna open it up to the four for questions, comments, feedback, Anyone? Big challenges, Big challenges, pain points is graph better than policy. You actually, You've got a, You've got a few more minutes to keep chatting, so Okay, cool. I'm sure I was pretty No, you've got about seven minutes here. Yeah.
Ah, okay. Oh, now I've done it. Now I've done it. I'm gonna go way over.
Anyone, anyone working with AI agents and they're terrified about how they're gonna do authorization for that. We, we all just clo we just close our eyes and ignore it and hope it goes away.
It, It's, we'll ask that next year and see what, It's interesting the way you were describing sort of the, the difference between static policy versus the dynamic sort of graph model. It makes me feel like it's going back to the days of compiled languages versus interpreted envir not interpreted, but environment languages. To me it's the difference between C and small talk, right?
And so in small talk, everything is there and it's live and you, you can invoke windows and it just all lives in front of you, but there's no document that you can go to that sort of starts at the beginning and keeps on going until you get to the end and then stops. And so I think it's, it's both, both are valid ways of looking at it, but are very different ways of thinking about what your environment is. And we were talking a little bit earlier in the concept of asking what ifs right? Becomes an interesting challenge where your policy is the truth, right?
If, if I were to say things like what documents could David access while he's traveling in Europe? Well, as far as the, the environment is concerned, he's not in Europe and if we put him in Europe then other queries are gonna go bad. And so when you've got that live truth it, it limits some of the thoughts you can look at. Whereas when you look at it on policy, it's really hard to look at some of the connections. I can comment, no, I'm gonna pick up The, the gentleman in the audience in the Up for that one. Yeah. Okay.
Well, I mean, alright, So if you have a knowledge graph, that means you have an ontology and you can ask those questions to the ontology. If you're using a graph that doesn't have an ontology, you can't. But if you use labeled property graphs, you can access the ontology and have questions on the, I mean answer those types of questions and more. Is any of that based on OWL or any of those standards that we're billing about? It's actually different.
There's RDF based, but this, this conversions Okay, Should we create zol Zol that Yeah, I always definitely the ontology language that's standardized. Okay. J just one point from my side is, I mean for us, we, we still treat it as like an enabler. So we would like hospitalization to be a primitive, that application, I mean there are three different kinds of developers. I see application developers or policy developers and data collected accurates or whatever it is for application developers.
If this is a primitive abstraction that they don't have to worry about, they would use it pretty easily, whether it's compiled into whatever way that makes sense for them. And the more and more use cases we start seeing are not necessary for just a single record and definitive access, we started seeing more prescriptive requests that are coming from our businesses where they would say that, Hey, if you access this, you probably are interested in that. Right?
And, and we wanna keep them engaged on our site as much as possible. So, which means that we have to keep proposing them services new and new and ask them to get onboarded.
So, so this place of very important primitive and personalization and recommendation journey and, and not just validating requests, at least for us that, that's the big enablement point that we see that authorization plays a very, very big role. And just to give some context for the audience, your use case is a B two, B2C, right? You're building a portal for Schneider's business customers and those employees of those Schneider customers should be able to get different access Exactly.
Based perhaps on policy defined by Schneider, but also based perhaps on other policies defined by the business user and or discretionary access where there is no logic, right? Exactly.
And, and, and we, we have a problem that we don't do the same business in each country. The product lines are very, very different. We call it long tail. A a lot of our focus is on decommissioning products that we, we can't sell anymore.
And it's, it's a big stuff for us to deal with end of life products and how we communicate, get them outta factories, so, and the legal entities that we have to deal with in other countries and other things like that. So every aspect of it has to be extremely dynamic for us.
And, and having this as an abstraction makes us give a very, very good experience for our customers. Thanks. And that's a shift that, that we've seen as well. I don't know if Patrick, you've seen that too, but go back five years, most of the products are policy-based products. Most of the products focus on mandatory access control.
But now, you know, Google came up with a model called Zanzibar in 20 19, 20 20. And of course you, you have an open policy agent that could be used sort of either way, like have you seen that same evolution from just policy to two poles and acls and Oh, and we kinda see both. It's my whole tangible intangible thing, I won't bring that up again, but it's, it's, it is Tangible. It's the idea when you're authorizing a specific object, like a specific file, then I see the whole reback thing becoming extremely popular.
But then when you have so much data that the authorization or the policy engine has to make policies about data that it can't uniquely identify like invoices or where there's billions of records, then it's still more of an OPA or alpha distributed authorization type of AAC scenario. Yeah, it's like I I'd say a hybrid, basically you kinda need both because the Reback model gives you the reverse query, the ability for the auditors to feel safe and comfortable about who really has access to that. And the ABAC is a little bit gives you the flexibility when you just absolutely have to have it.
So I don't see any one, but definitely there's a big push in both, both trends. Yeah. So any question from the audience? Great. Good morning.
Hey, you're expressing that authorizations are expressed between users but also see authorizations for between organization, between organizations as legal entities. So I was wondering, is Schneider also a documenting something that in your policy exercises? So we do have requirements. I mean typically the authorization exercise where two companies are involved comes in like special pricing agreements and other things like that. In most cases we rely on some SaaS product that does entitlements for us. And in our experience, it's not externalized and standardized as we would like it to be.
So every other time we get a new, let's say pricing management product, we have to adapt to this whole thing again. And this is where we see this authorization. Having a strong tie up with entitlement management can help us a lot in externalizing this.
Yeah, I'm involved in data spaces between organizations and you see a lot of discussions around yeah, giving authorizations to other organizations and it's quite a similar one, but also with different aspects. Speaker 10 00:23:45 I think There is EDI is the closest authorized, authorized connections that we have, like between two ERPs where we say, all right, we, we trust now we connect directly between two systems. We'll discuss how much discount we give you on the volume of business that you do. But it's a very, very old standard.
It's not, we are not able to use that for driving experiences and other things like that, which is my main focus. There was research done more than 10 years ago now under one of the EU research frameworks of P six about creating what was then known as virtual organizations, but to see it as federations of businesses. And in there the research project did translation of legal contracts into BL documents for business processes and then authorization was expressed to Zac Wall and that that actually worked well. And Zal actually has a delegation model that you can use in practice.
We've never seen customers use it. It it, it got a little too complicated. So I think as we look into Zen in the future and as we look into Alpha 2.0 in the future, maybe we have to rethink about those, those use cases. Speaker 10 00:24:54 We have an operational, the I share framework Using what technology? Homegrown or sorry, using what technology?
Yeah, Speaker 10 00:25:03 The second base, Jason Military. Oh, cool. Yeah. Awesome.
The, there's another proof of concept that was done in New Zealand in about 20 15, 20 16, something like that. And they used, it was specifically looking at UMA, which is the profile on top of OAuth and the concept of having delegated access between not only organizations but between individuals within organizations. And they had some really interesting use cases that they were looking at. For example, you would have where a student was delegating to a employment agency, which delegated to a particular person, managing them who ultimately has access to, to the resume and the work.
And I think if you do a search on Google and look for the New Zealand POC around 2015, there's a bunch of really interesting use cases covering that exact point. It seems like verifiable credentials is gonna have to come into play Here.
It, it may, one of their use cases was really interesting and that was how do you deal with a non, an immigrant who is not yet in the system, right? And so the delegation was to a local registered agent and there was actually no electronic connection with the, the ultimate immigrant. Sure. And then you had to have a point where they were, they were digitally born, right?
And they, they sort of came into the system and then things moved between them. So there were some really interesting use cases around that kind of thing. Okay guys, do You wanna wrap up quickly? We've got about just to conclude in some way from what Yeah, so quick call to action from the, from us, the author and family come look at us or the standard, not us or, or or we, We, that wasn't what I meant. Actually. We will create A Patrick's not gonna say, oh come look at us. We will sell a calendar of, you know, one month, one photo of us writing authorization policies.
But joke aside, you know, teacher developers to think in terms of externalized authorization, that's the biggest win. What you use behind the scenes doesn't really matter. So much of Zen is here to sort of decouple that for you.
Patrick, one last Word. I'd say now, now that things are, you know, coalescing is a good time to get your feedback and your desires heard. So try to get involved. We need use cases.
Yeah, definitely bake it in there and make sure it covers a lot of a broad range of scenarios, so it's something people will adopt. Yeah, I mean I I, after listening to Alan and David also, I, I started expressing more interest in sharing use cases from our enterprise, et cetera. I think it, it seems to be valuable, so I, I'll definitely be actively contributing as much as I can.
Yeah, as David said, if you have use cases like the delegated enterprise one come in and talk about them because sometimes we just don't even think of them. And getting those into the set of use cases means that we can start looking at solving problems people are actually solve facing. Fantastic. Thank you guys. Thanks for a great panel. Thank you.