Panel | Policy Engines in Practice

Okay, but if you could, before you start moderating yourself, if you could just introduce yourselves and what would this is actually should be about policy engines, which is something that I'm quite interested in. So let's see what you have to say. Thanks. Good morning, everyone. Good morning, everyone. Is everyone still awake? Just about cool. Awesome. My name is David. I'm the CTO at Axiomatics. I've been in the authorization world forever, almost. I used to be one of the editors of the SACWOL standard, and I'm now a co-chair of the Zen Working Group under the OpenID Foundation.

And with me today, we have Patrick Parker. Patrick, do you want to introduce yourself? Sure. Nice to meet you. I'm Patrick Parker. I'm the CEO and co-founder of EmpowerID. Authorization is my own personal favorite topic in the area of identity. And I've been in the identity business since about 1999. So all-timer, definitely.

Sid, do you want to introduce yourself? Hi, everyone. Is it working? Yeah.

So hi, I'm 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 pull them in. Alan? And I'm Alan. Alan Foster, one of the original founders of ForgeRock. I've been involved in policy, and David and I first met on the SACWOL Standards Committee way, way, way back when. And so looking at...

And I'm going to step back from access management for a minute and just have a look at the general prospect of decision-making within the enterprise, the sort of one that's my little bugbear. All right. And our main mission, really, collectively here, and a few other folks in the audience as well, is to make authorization a reality.

One thing, if we look at IAM and authorization, I've been at it for over 10 years, you've been at it for over 10 years, and still hasn't gotten to that aha moment. It's a really hard thing to crack. So maybe starting with Alan, what do you think it's been that way? Why policy engines and authorization are not there yet? And will we get there? It's been an 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 all sort of agree as to who it is. And that's 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 bearer token kinds of problems and others, but it really solved those bearer token problems, which meant that the demand wasn't really a tidal wave coming over us. It was just that delta up at the top for the really complex decisions. I think that's sort of why it's taken time for us to get here. Thanks.

And Sid, 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 Alan said. What's your main takeaway? Sure.

I mean, my journey primarily started with personalization. So our goal is we want to 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, can it figure things out? That's where we, and that was the main objective for us. We have so many different teams that don't want to learn all of these things. We want to manage that for them so that they can focus on getting the right data and giving the right experience.

So that kind of triggered our whole journey where we want to centralize and then externalize. In that externalize, 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 took us halfway. And then we said, 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 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 ID equal to something and get the data. But we want to have this as an abstraction at every level. Like zero trust is a fancy thing, but we would like it if that's a solved problem and we just focus on experience. Thanks. Wouldn't that be nice? Yeah. That's a great T-shirt. It just works. So we're moving to a model where we're just going to ask people to do the right thing. We don't need authorization. Just please don't look at other people's stuff. Can we trust you? I want to bounce on something you said, Sid.

You wanted it to be easy and understandable and developers not have to worry about that. So before I ask you the question, right now in authorization, there's two main camps. Policy as code 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 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 basically for this workshop, I took the standard information from the website, vectorized it, fed it in, and then designed a multi-agent LLM where one was 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 actually proved very interesting, very accurate.

And you could then, so by telling the agent that it was an expert in OPA, Rego, Cedar, 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. You could ask it almost any type of question, natural language question, Austin 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 possibilities there.

And it also leads into explainable AI, because 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 why it came to that conclusion. So transparency is going to be much better. Thanks. We had a bit of a chat. So two things. We actually did an interop again this morning from 9 to 11. If you're interested in the notes, we can share those notes. But Alan also had a bit of a chat with Martin Kupinger 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 gatherings, and so forth, kind of what you were alluding to with LLM, but also the bottom up. So two questions. One for you, Alan. What is AuthZen 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?

Alan, AuthZen? Okay, so let's start off with AuthZen. We realized very early on that 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 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's sort of the same kind of question.

And so 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 we got down to a point where, yes, let's start down at that where we've really solved 90% of the problem, and let's try and standardize that moving its way up. And I think 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 policy definition, policy language compatibility up at that level. We'll get there eventually, but that's probably where the translation layer that you were talking about fits in quite nicely. And I'd like to explore that some more soon.

But yeah, 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 result. The fact that you could choose which policy engine you were hooking up to and start doing some actions. We have 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 going to 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 freeing thing.

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?

I mean, when we attempted to bring this to developers, business analysts, and everything, we struggled a lot by, we initially thought, 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 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 tried to prioritize UI in the beginning because we thought 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 OAuth2 as a solved thing, I have many developers who don't know how OAuth2 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. 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 am 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 in a way. So hopefully, having standards like OAuth10 is going to 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 hope they would read it. Pivoting slightly to the discussion around policy, I want to 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. So the idea of being able to do query, if then else, and 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 we've all been through the thing where you're building an app and we're 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 going to get half of them wrong. And that adds in the break, whereas in a policy you can go in and say once and executives and get 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. In yesterday's presentation, Adam Rusbridge, who was 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 going to go down by 60%, or the cost of doing authorization goes down by 60% because you don't have to have spaghetti code within the app. And 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. It's not just the audibility, 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 which data, which rows should I be able to see? 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 want to open it up to the floor for questions, comments, feedback? Big challenges. Big challenges, pain points. Is graph better than policy? You've got a few more minutes to keep chatting. So yeah.

No, you've got about seven minutes here. Oh, now I've done it. Now I've done it. I'm going to go way over. Is anyone working with AI agents and they're terrified about how they're going to do authorization for that? We all just, we just close our eyes and ignore it and hope it goes away. We'll ask that next year and see what. It's interesting the way you were describing sort of 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 environment, not interpreted, but environment languages.

To me, it's the difference between C and Smalltalk, right? And so in Smalltalk, 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 a 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 I were to say things like what documents could David access while he's traveling in Europe?

Well, as far as the environment is concerned, he's not in Europe. And if we put him in Europe, then other queries are going to go bad. And so when you've got that live truth, 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. 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, I mean, answer those types of questions and more. Is any of that based on OWL or any of those standards that we're milling about? It's actually different. It's RDF based, but it's conversions. Should we create ZOWML? ZOWML is definitely an ontology language. There's standardized approaches. Just one point from my side is, I mean, for us, we still treat it as like an enabler. So we would like authorization 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 accurators 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, interpreted, whatever way that makes sense for them. And the more and more use cases we start seeing are not necessarily 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.

And we want to 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 on boarded. So this plays a very important primitive in personalization and recommendation journey and not just validating requests. At least for us, 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 B2B2C, 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 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 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 lot of our focus is on decommissioning products that we can't sell anymore.

And it's a big stuff for us to deal with end of life products and how we communicate, get them out of 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 having this as an abstraction makes us give a very, very good experience for our customers. Thanks. And that's a shift that we've seen as well. I don't know if Patrick has 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 Zenzibar in 2019, 2020. And of course, you have open policy agent that could be used sort of either way. Have you seen that same evolution from just policy to tuples and ACLs? And we kind of see both. It's my whole tangible, intangible thing. I won't bring that up again. But 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 policy engine has to make policies about data that it can't uniquely identify, like invoices or whether there's billions of records, then it's still more of an OPA or alpha distributed authorization type of ABAC scenario. Yeah, it's like, I'd say a hybrid, basically, you kind of 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 trends. Yeah. Any question from the audience? Great. Good morning. You're expressing that authorizations may express between users, but also see authorizations between organizations as legal entities. So I was wondering, is Schneider also documenting something that in your policy exercises? So we do have requirements.

I mean, typically, the authorization exercise is where two companies that 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.

I'm involved in data spaces between organizations. And then you see a lot of discussions around giving authorizations to other organizations. And it's quite a similar one, but also with different aspects. I see. There was... EDI is the closest authorized connections that we have, like between two ERPs where we say, all right, 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.

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, FP6, 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 BPEL documents for business processes. And then authorization was expressed as ZACML. And that actually worked well. And ZACML actually has a delegation model that you can use.

In practice, we've never seen customers use 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 use cases. Using what technology? Homegrown? Using what technology?

Yeah, there's a second one, face-to-face. Oh, cool. There's another proof of concept that was done in New Zealand in about 2015, 2016, 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 an employment agency, which delegated to a particular person managing them, who ultimately has access 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 going to have to come into play here. One of the use cases was really interesting, and that was, how do you deal with an immigrant who is not yet in the system?

And so the delegation was to a local registered agent. And there was actually no electronic connection with the ultimate immigrant. And then you had to have a point where they were digitally born, right? And 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 want to wrap up quickly? We've got about just to conclude in some way from what...

Yeah, so quick call to action from us, the AuthZen family. Come look at us, or the standard, not us. Or us. That wasn't what I meant, actually. Patrick's not going to say, oh, come look at us. We will sell a calendar of one month, one photo of us writing authorization policies. But joke aside, 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. AuthZen is here to sort of decouple that for you.

Patrick, one last word? I'd say now that things are coalescing, it's 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, after listening to Alan and David also, I started expressing more interest in sharing use cases from our enterprise, et cetera. I think it seems to be valuable, so I'll definitely be actively contributing as much as I can. 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 facing. Fantastic.

Thank you, guys. Thanks for a great panel.