How AI Can Help IAM Deliver Better and Stronger Authorization

I live on the west coast of Canada, which is a 10 hour flight and a nine nine hour difference. So I'm a little jet lagged if, if I fall asleep. 'cause the presentation is boring. Just please just wake me up or not depending.

So yeah, my name is David, as you Allall know, I work for a company called Axiomatic. We specialize in, in fine-grained externalized policy-based authorization. That's a a mouthful. Externalized authorization is, is an an emerging market. It's been emerging for the past 10 years. It's maturing though, and there's lots and lots of new initiatives, new companies, a whole new way of doing authorization. And the talk today is gonna be focusing on how AI can actually help us address authorization in a more efficient way. Oh no. Oh no. Well that was my presentation. Thank you very much.

I was putting the final touches on my deck last night 'cause there's nothing like just in time presentations. And I was only like three minutes into PowerPoint when this happened. I'm a Google Slides guy and I now remember why I'm a Google Slides guy.

All right, so enough, enough about that. Before we talk about AI and how we try to use AI at axiomatic to make authorization, authoring and authorization management better. Let's take a step back. Who here is familiar with externalized authorization? Nevermind OAuth authorization, but externalized authorization.

Okay, great. Cool. Last week at iver, I hope I'm allowed to say that word here.

We, we came up with a, a new way to look at authorization historically, you know, if we go back all the way to to, to 2010, when I started working in authorization, we really pitted runtime authorization, which is all about PET PDPs and so forth against admin time authorization, which is more about doing authorization through your sessions, through your identity management, through your, you know, typical for rock ping and so on, so forth. But then we realized that there's another type of authorization, which is event based authorization.

It's the whole idea that now that you've been given entitlements to do stuff through your admin time authorization, maybe we need to make your session or your token or your entitlements evolve. So that's event based authorization. So think of those as three models that you can combine together. They're not exclusive, right? You still need to have your roles and your entitlements, your birth rights if you will.

You still need runtime authorization to determine what you can do right now there and then through policy, some might say through graph, but it's mainly through policy to be honest, right? No heckling this time, Alex. And then of course if you did wanna update your policy or your configuration or your sessions, you could use event time. Things like within the Open ID family, you'll find stuff like Risk and Cape. So it's an exciting time to be in the authorization world. This is your typical runtime architecture. You have a PEP that is responsible for protecting your resource.

This picture, by the way, comes straight from Wikipedia. So if you go to the, I think the Zack page for Wikipedia, you'll find it there. I stole it from Wikipedia. It's okay because I put it there in the first place. You have a PDP, your PD DP could be policy based as is the case for us axiomatic and a bunch of other vendors. It could be graph based, it doesn't really matter. Okay? And then you have the management of policies in the pap and your sources of attributes in the PIP. So externalized authorization in my mind at least is ABAC attribute based.

Any number of attributes could describe the user, could describe the resource, could describe the context, could describe the action that you wanna do. So if I say manager view, document managers an attribute, views an attribute and document is an attribute. Okay? You might hear the term pba, I think it's a double DG go bonus points if you know how to spell that word. I never get it right. It's just aback, right? And then you can use policies or you can use graphs and so on and so forth. It's also reback. You want to exploit relationships between the user and the context and the resource.

For instance, I wanna view my own medical record, not anyone else's. I also wanna talk a little bit about, of Zen. Of Zen is a new initiative under the Open ID Foundation about standardizing interfaces between the PEP and the PDP. So going back one slide, the pep PDP in Zac Bull Land and Alpha Land has a protocol, but that's only for a couple of vendors that support Zac Bull. The rest do not. So if you're in OPA land or graph land, there is no standard. So within Open id, we decided to actually create a standard called Zen. We focus on three things. One is the request response protocol.

pep PDP two is design patterns. How do you wanna do authorization through runtime, through tokens, through sessions. And three is the policy administration piece. So if you wanna join us in Zen, we're looking for more members. We did an interop last week at Ivers. We're doing another interop on Friday. I'm happy to say that we have 12 different implementations or 12 different vendors and, and frameworks taking part, including the OPAC camp, including the Zac Wall camp.

And yeah, if you're interested, please join us on Friday. And actually in two sessions time we're doing a, an zen panel. So stick around in this room. And then the last thing, externalized authorization is also alpha, the abbreviated language for authorization. It's a way to write your policies, policies as code. You can manage them in a central place. You can manage them in GitHub, wherever you want to have them really live. And Alpha uses. Yes sir. No Alpha uses attributes of course. Thank you. So it's also policy based in my book at least.

And the whole point of policy based is that you can write policies in pretty much plain old English. One of the challenges that I've been facing, I just went from 20 minutes to 10 minutes. Am I that slow?

No, the, the counter. One of the challenges that I've been facing when I talk to, to customers is that they tend to think in terms of roles and groups and entitlements. There's that strong urge because we've been taught by the identity management family to think in terms of roles and our back and groups that we wanna do that role engineering exercise time and time again. But actually with policy driven authorization, with externalized authorization, you have an opportunity to think in plain old English.

So thinking in plain old English is saying things like managers can do their customers accounts. We all understand that. And manager is not a technical role, it's a business role. It makes sense. We know what a manager is. It could also be customers can transfer up money up to their daily limit. Okay? And maybe daily limit is a parameter that the customer can choose. So they could say transfer $200 only or $500 Canadian dollars.

Mind you, it could be customers can see a dependence account. And this is actually quite cool because now you can build, you know, authorization oftentimes is thought of as, as kind of a security mechanism, but it's also an enabler. So doing customers can see a dependence account, you're creating new use cases where now as a parent, I can see my child's account, or as a child I can see my senior parents' account because they're not capable of doing banking anymore. So see policy-based authorization, externalized authorization as an enabler of use cases, not just applying security.

And then one more thing that's quite cool that I believe graph can't do is negative policies. Customers cannot transfer money after say 9:00 PM Yes sir, in the audience over there, do that. You can do negative statements.

Damn, I don't believe you. And it's all, all a hundred percent attributes. So you're like, well, hang on a minute. I came for the AI and all I'm hearing is all authorization. AI is not magic. I'm sorry to say that I debated whether to put this slide at the very end of the deck or as a warning at the very beginning. But either way, AI is not magic. It's just meant to be an assistant. And we're gonna see that and see how AI can help us build a better authorization experience.

As a side note, last week, I dunno if I mentioned it, but I was, I Iver and we went to a magic show of a, a couple of guys called Penn and Teller. Does anyone not know Penn and Teller? I thought they were dead.

They, they might be dead. I mean they cut each other in half.

So yeah, who knows? And we, we got to be on, on stage and we surrounded an elephant, actually a cow dressed up as an elephant and, and the cow disappeared and it was a chicken. I dunno how they did it. They must me using ai. So how can AI help?

The short version of this presentation very briefly is Aiop AI can help with education, with helping people understand the, the shift from the traditional sort of identity centric way of doing authorization to the more policy driven way, way of doing authorization handling both identity attributes, but also resource attributes and the relationship between them. So last week I was in Vegas, but this week I'm in Berlin. So here we go. Alexander Platz. I'm very jealous that Alex gets his square and I don't get, David Platz i's very jealous.

But anyway, so there's six main points I think where AI can be helpful. Number one is just get your authorization done more quickly. Get that support helping in, in the pipeline of building your policies, identifying your attributes, defining your authorization requirements. The second step is more specifically defining the authorization requirements. Going from, if you're building an app and your app is a, a ride hailing app, say Uber, you know that you want people to be either a driver or a writer, fine. But then what are the authorization requirements?

Maybe a writer cannot see the driver's location until the ride has begun. So there's authorization requirements that AI can help you identify and in particular identify gaps that you haven't thought of. It's also converting policy into code from English into code. And I'll show you what that looks like. It could be doing analytics, it could be translating between authorization languages. I'm assuming everyone knows XKCD. There's a famous picture in XKCD that goes along the lines of, oh my goodness, there's 14 standards to do authorization. We need to solve this a month later.

There's 15 authorization standards. So please don't reinvent standards. Says the guy who just did zen. And then lastly, help developers with integration. So the first step is really helping overall with policy authoring. When you start your authorization journey, again, we come from this RAC mindset. We have to think about a model, a lifecycle that's gonna take you from your app requirements into your authorization requirements into the building box of those requirements.

What I would call attributes into the policies that use, use those attributes with ai you could actually throw a problem at it and say, Hey, I'm, I'm building this medical journal app, what should I be thinking about? And ideally AI would reply back and say, well, there's privacy concerns, there's data sharing concerns, there's maybe border exchange information happening. Maybe you wanna share the data with the insurance company. And the insurance company should be able to see all of your medical data. The second step is gen AI can actually help define the requirements more specifically.

So if I write, I'm building my medical journal app and a doctor should be able to view the medical record and the medical notes of a patient that is in their care, then ideally you want AI to be able to translate that into a more structured English way. And the way that I, that, that I was doing it before AI came along is I would teach customers to think in a subject verb object environment or context way. But now with with ai, you can become a little lazier and just write some text in the tool and it can spit out that structured English format for you. Bear in mind that it's not a cure all.

You can't fully trust ai. Of course it gets stuff wrong all the time, but it's a hint, it's a really good hint of where you want to go with the authorization requirements.

Also, it can help you, like I said earlier, identify the gaps. Did you think about all the use cases? Did you think about the negative use cases? And that's actually quite important if only to have the conversation back and forth, especially if you feel lonely. 'cause you work very far away from hq. So you can have that back and forth with ai. But to give you an example, I, one of our, my customers many, many years ago was a defense ministry somewhere in Europe. And the person who was doing the policies had thought through the policies extremely carefully that done a really, really good job.

They were very well structured with the one minor issue that he, he only had deny policies. So it was like, you can't do this, you can't do that, you can't do that. But they were well written like it was subject object, verb or I've been in Germany too long and putting the verb at the end of the sentence subject verb object. But there was no permit case. So right AI could have helped him say, Hey, hang on a minute. You need an actual allow case.

Going a step further, if you have your requirements well structured in English or pick your favorite language, then you can also ask AI to do a bit of mapping into your target language. So it could be alpha, it could be rego. The more constrained the language, the the easier it's gonna be. So alpha is a better target than rego because rego is so powerful and so broad that it can be hard to map concepts.

But again, when you do that, you wanna make sure that the output makes sense. And right now we, we have a a of course, this is of course a, a biased presentation. We have an AI policy companion that will do that for you right now. It works in a vacuum. It is not connected to any underlying attribute dictionary. So it creates attributes every single time. But the next step for us is to connect it to the dictionary so it can use the vocabulary that we have predefined and that will make the policies even better than just randomly generating those policies.

So this is what actually it looks like, imagine this text on the left, A customer analyst with the role analyst and department da da da is allowed to view customer information. This is plain old English, this is actually not even structured. The first step you'd wanna do is digest this piece and then once you've digested it into a structured English format, then you can take it over to your policy on the right hand side. And this is an example of what alpha looks like. Very simple.

You play with attributes like user role, you compare it to the value analyst, then you can bring in considerations like time of day. And of course you could do relationship based access control by comparing the the customer's region to the analysts region. Okay? It's actually pretty simple. It's really not rocket science. You can also do with AI enhanced analytics and access reviews. That's actually a big, big deal and it goes way beyond authorization. It also goes beyond ai.

When you have externalized authorization and you have a PDP that you query for authorization data as opposed to relying on on tokens and and sessions and so on, you actually have an audit trail of what people are trained to do. That's quite cool.

You know, that a user has tried to view customer account 1, 2, 3 at 2:00 AM from Singapore, you know that information, you know, whether access was denied or granted, you know, all the attributes that were used. So you can mine that information and you could do that before ai of course you could just use, you know, Splunk or your favorite SIM tool to do that analysis. But now with AI you could actually do more learning. You could figure out, well hang on a minute, I've got a policy about feature X and feature Y and feature Z. My audit logs never ever talk about feature Z.

So either number one, there's a misconfiguration in your system or number two, no one cares about feature Z or Z depending on where you live in Canada, it's very confusing. So AI can help you understand that AI can help you also mine your policies and understand what the policies represent. That could be policies that someone else wrote and then they left the company and they didn't document the policies. So you don't really know what they do. So feed the policies to AI so that it can tell you, oh this is what the policies represent and by the way, we think there's a gap.

We can also translate between authorization languages. Does everyone know what this is a picture of or is that a stone?

Yeah, found by the French, stolen by the British. I'm French by the way, so I can you know, say that you steal it First. Did you steal it first?

No, I think the French stole it first. The French are really, really good at stealing.

So yeah, there is not one single authorization standard today and and most likely we're gonna see, you know, additional standards emerge in the future, right? So if you go back to 2001, you had Zal created by Oasis, kind of a sibling to saml. If you go to 2012, you have Alpha. If you go to 2015 roughly, you have Rigo, Alex from Voss is talking right after me.

They use, I think you use your own language, right Alex? Yeah, there you go. So different ways of expressing different languages. AI can help you bridge those languages so you can move from one to another because at the end of the day, like what the PDP runs to some degree you don't really care. It's the fuel that goes in the car. But what you do care about is the management and the audit and the access reviews on those languages. So you could use AI to bridge between those.

There is another initiative called IDQL by hexa, which is an open source framework that aims to also help with the bridging between the different authorization policy languages and translating from IDQL into opa into, or Rigo I should say, into Alpha, into other languages, right? How am I doing on time?

Okay, so yeah, translating between Alpha Opa, Cedar as an example, it works pretty well. Bear in mind that some languages are constrained like Alpha and re and sorry, CR others are broad like Rigo. So the translation ability of AI really depends on the language that you're dealing with. It's gonna be easier to go between alpha and Cedar than it's gonna be between Alpha and and and Rigo.

Alright, and last thing, gen I can also en enable developers. We shouldn't forget. Developers writing policies and defining authorization requirements is all nice and well. But if you do not connect to the app that you're dealing with, it kind of all falls apart. And connecting to the app is really defining that pep that we were talking about earlier.

So the zen piece that I mentioned, but also defining the authorization request that you wanna send, defining the expected authorization response and AI can help us generate a bit of code, a bit of JavaScript, a bit of type script that'll do that for us. So just imagine a world where you write a policy either yourself or through ai and you click on a button that says, deploy the policy and give me the, the, the pep stub, gimme the, the code stub in Python and whatever.

And boom, you get a sample that you can quickly adapt. 'cause you'll have to adapt and review of course into your own application that's gonna help do that authorization lifecycle way more quickly. On my way home last night from dinner, I, this is actually the intersection that's right in front of the B, C, C and I saw this traffic light that I was really confused with. 'cause I know what green means. I know what red means. I don't really know what blue means. So should I cross with my bike? I'm not too sure either way. The point is that authorization is just the journey.

It's just an enabler of cool things you can build. Oftentimes when we talk to customers, when they come to us about authorization, it's, it's almost always in an I am context or in a security context. They wanna make sure that they respect privacy, that they're not in violation of say GDPR or or something else. But also think about what authorization can enable. It's also an enabler of things. Think about the fact that 20 years ago your medical records were on paper at the doctor's office and the only way to see your medical record was to go to that office.

Today you can see them online and hopefully just you and your dependents. Not the bad guys.

With that, thank you. Thank you. Excellent. And thanks for doing a presentation that mentioned AI without any of those hideous AI generated diagrams that everyone else seems to come up With.

I, I got lucky I didn't this time. I sometimes do, so.

Ah, No, please don't. Anyway, any questions for David in the audience?

Okay, well thanks again. Thanks.