Unpacking Authorization Approaches: Policy as Code Versus Traditional Business Needs

Hello everyone. Welcome to the pre-Conference Workshop. Unpacking authorization approaches policy as code where the traditional business needs today. Our speakers are Alex. Hi everybody. David. Hey everyone.

Oh, Patrick and Philip. Hey, Would you introduce yourself quickly, please?

Phil, you wanna go first? Yeah. My name is Philip Massa. I'm a lead advisor for Coing a Coal and I'm happy to be here. Alex Banu, CTO at three edges and generally referred to as the graph guy David Ard, CT Axiomatic. I'm his neighbor and generally referred to as the policy guy, which is way better than Graph by the way. Obviously not Patrick Parker. I'm the CEO and Co-founder of Empower. And you can call me Patrick. And my name is Justin Gob. I'm the advisor at Co Cole call The agenda. The first point is about definitions and foundation.

We want to lay a foundation for the next step. Chap chapters and chapters and agenda points on the second point is authorization management. This will help tend over by David and governance challenges will be done by Patrick. And after that, the case study, we have one case study and these case studies will be done seally by every partition speaker. So after the case studies and the authorization models, we will go deeper in the future strategies of authorization. And with the last agenda, point, 0.5, credential strategies. We want to give you a insight how this can be done.

The definition and foundation, it is our duty to secure access and ask the right questions. So who has access to what, when it should be accessed, where is the access coming from and how the access should be done. For example, also, what resource the the, the access wants to be done. So first point, what is an authorization model? An authorization model is a framework or methodologically used to determine and enforce access policies within a system. It specifies who is allowed to do what in a system under which condition.

Essentially defining permissions for users or groups to perform specific actions on resources. We have four different aspects.

Sub, sub subject, action, resource, and context. Subject is the other entities like identities, groups, users, devices, machines that request access to resources. Action are the operations. The subjects want to perform a resources, for example, create, read, update, delete actions, resources. Resources are objects or data within system. And the subjects wants to access such application files, databases or services context. These are rules that define under which condition the access is rebranded or denied.

Condition can based on, for example, various attributes such as user roles or also security levels or location and device ID from predetermined access to adjust in time evaluation. At in admin time we do define policies and they result in runtime or for example, also in event time. On the next slide you will see the most common AC category. And this is still admin time. Admin time is before the user logs in. And the market term for this is identity governance administration tools.

The capabilities which are held on for our admin time are user provisioning, role management, access requests, access certification, privilege, account management. And also the authorization models used by admin time are, for example, access control list, which are the, how to say it, the core or or where the foundation started. And authorization models like Arpac or Google, Zanzibar, Reebok in one time. We have when user user logs in, and this is access management, we have here single sign-on capabilities federation, strong authentication and authorization.

The authorization models used by runtime are aac, risk behavior, access control. And in event time we have, when the user is already locked in, though we have no market term defined yet. And for the capabilities we have signal processing, transform and signal auditing. The authorization models are here, SAP share signals or risk.

But yeah, on the next slide we see fine rate authorization. We have three different definitions for that. So what we want to say with this slide is, well, there are many definitions but there is no common definition in the industry. And the next point, we want to, we want to cause drain versus fine grade access control. The definition for our case is for core strain, is it grants or denies access on a single factor. Fine grade access control defines or grants or denies access to data resources based on multiple factors.

The strengths of cost drained similarity, it's easier to set up and manage. And due to fear, broader permission settings, efficiency, it reduces the administrative overhead associated with maintaining detailed excess controls and scalability. Easier to scale at the number of users and resources. Growth as roles and high level permissions can be reused. The strengths of find grade access control precision ensures users have access to exactly what they need and nothing more.

Enhancing the security flexibility allows for the creation of complex and dynamic resources that can adapt to various scenarios and conditions. The challenges which we have with fine grain or cost grain. With cost grain, we have this challenge, lack of precision. It is the strength for fine, fine grade access control, but the challenge for cost rate, access control, lack of precision, our provision of entitlements users may have more access than necessary.

So increasing the risk of unauthorized actions and data breaches flexibility harder to tailor access controls to specific users needs or changing requirements. The authorization models simplify it here for cost grain are are a and the challenges for fine grain access control, we have complexity more challenging to set up and maintain due to the detailed nature of the permissions and policies. Administer of overhead requires more effort and resources to manage especially, especially in large or dynamic environments.

And the performance can potentially impact systems performance due the overhead of our evaluating detailed access policies. And for that we have the alteration model A back, so fine grain canola conditions or granular resources. Here we see the condition granularity and the resource ality. These are two different aspects we see.

We see for the subject for example, in the conditionality where either item type is internal and the signed NDA is true, this means the subject is an internal employee and TS signed and NDA for the resource he wants to, he wants to access, there's a country he wants to access the resources from the country Canada and the dock type invoice with the value over 2000 context. The context is where trusted computer is true and the current time is the working hours. There we have a, we have the context.

It says you have to have a trusted computer and you have to have the current time of the working hours. So yeah, ab abic typically required is for this, the resource loyalty. We have to have only the resource aspect. And this is the object level, file level, row level and the column and attribute level. For the next slide, I want to hand over to Philip.

Yeah, thank you Yasin. So for the next slide, we talk a little bit more about authorization models. And I've borrowed that slide from Martin cupping itself. He uses that, uses that slide usually to explain how ABAC works, how policies work. And he usually says that policies can be expressed in a business language. And for expressing those policies, that rules you can find very simple terms. But in general, when we design a policy, we have four C components in it. The subject, the action, the resource, and the context to describe what a subject is able to do.

This is how you speak or how you design it from a business perspective. And since we are talking about authorization models today, it's important to understand those dimensions. So we will dive a little bit deeper into that and try to understand how that looks from an authorization perspective from the authorization manager. So here on the upper half we can see the end user view. When the business user designs a policy, he would, he would probably say, Anna can access the folder sales for Germany.

So you can, you can exchange that sentence by, by any kind of rule or policy that you want to use. But it works the same way. The idea is that we have a subject, we have an action, we have a resource and a context. And that looks a little bit different when we, when we see that from the authorization management perspective. When we think about that, how would we grant that access? So usually when we talk about that, we still have the more or less the same object. We have the identity or the subject.

You can, you can exchange that we, instead of the action, we have the, the challenge to grant that access by either a decision making process or the provisioning in advance. We have the resource and and as object. So the entitlement and we need to use the context in some way to make sure that the rule or the policy is able to, yeah, to to be executed in the right conditions.

So from the authorization management perspective, that means that when we rephrase the sentence that we have above that Anna can access the folder sales for Germany, we rephrase that a little bit because the context from an authorization perspective is part of either the identity and attribute of Anna in this case, so Anna from Germany, or it is an attribute or a context of an object. It's not standing alone somewhere in the identity space. So rephrasing that from an authorization perspective means that we can, that we say the identity Anna from Germany can access the folder sales.

When we think about the decision making process or the provisioning in, in that idea, we have heard that by YAI in that we have the admin time aspect and the runtime aspect. And it, it depends on when you are trying to to give the person that access. So if you go for the admin time access, you will provision that in advance so that there is not really an action when at runtime when the user tries to access that folder. So in that terms, Anna, so the sentence would be rephrased into Anna is added to an ad group for sales, for example, could be anything else.

But it happens in advance when we do that in runtime. So when Anna is trying to, is trying to access the for sales, we use a policy to check that at runtime and execute that policy in real time. So that means we, we need to define a condition when we want to grant access. And this is the if ger, if, if Anna is from Germany, she is allowed to access that folder. And that folder in this term is the object, the resource, it is sales.

So this is just a small example for how modern authorization works and how two of the many different authorization models can work from an authorization perspective. And when we think about that, and we, we had the discussion already or the definitions around Arba and abac, let's think a little bit about which authorization model, and I've taken those two as an example here, focuses on the different dimensions in this terms, the this decision making and resource and the object. So when you think about RA, and I'm starting from the right, right side to the left here, what is Abe doing?

So ABE is the most commonly used authorization model. So we probably all know it. We have not defined it in particular this because we think you all know it. The idea of a is to cluster access into roles, enhance those roles and provide them to the user so that we don't need to, that, that we have less effort for assigning roles. The idea of ABE, however, is all about the resource or the object. So it's basically to improve the transparency of the object, cluster it into roles and enhance it by certain conditions or attributes or anything.

But it's not really talking about the identity and it's not really talking about the decision making process, neither about the provisioning itself, which is usually handled manually or in a one-on-one term. So what is the goal of a EC here? With the focus on the object, the goal is really to, to make the resource more understandable. It's nothing else. It's about enhancing the resource, making that bundled or bundling access into a single role. So what does that mean for a a as an authorization model in the future? So we often, here at EIC also in the last years, a a is legacy.

There is no future in a a we all needs to be done in a a, I think it's not that easy to be honest, but Abe in the sense that we use it for role modeling and, and granting access a with roles needs to develop, this is the least, we have to say it, it will not stay like it was in the last years. That is only focused on roles itself.

It's the, the, what we see in the future is more that it needs to develop into an authorization model that is focusing on enhancing the object, providing more information on the object and resource side. On the other hand, on the left side here, we have a, a and abank is all about putting rules and logic into place, formalizing it into sentences that we can execute to grant access. That's pretty much the idea. So with that, the focus is primarily on the decision making end here, not so much on the identity and not so much on the resource.

So usually we can use the ABE approach for, for single resources, but it's not really talking about providing roles or bundling anything into roles. So the focus primarily sits here on the decision making part. So what is the goal? Primarily scalability. So we want to provide as much x or as much access as possible in a certain amount of time. It's not about providing more transparency or enhancing the object or the identity. It's really about the decision making and being scalable in an automated way, of course. So how will Abe develop?

This is also a thing that we heard a lot on the last EIC and the EICs before. abec is the future automation, scalability. We need to become more efficient and, and this is really what abec is about, the scalability, the zero trust approach. This also a thing that we heard a lot with abac.

Yeah, full stop here. One thing that my colleague added to the slide is the reback model. Just to give you a little lookout into other authorization models here. So Reback is combining a, a and RA very simplified said here, and I'm not going much more into detail that can Alex do later if he, if he wants to. But the message of the slide here is RA and a a neither Reba alone will not work. So we need other authorization models in a combination here. And this is really what we also have on the takeaway slide here on the conclusion slide for the first chapter.

There is not a single authorization model. Usually you combine those models. So when we think about Abe with a strong focus on the object and Abe with a strong focus on the provisioning, on the decision making area, if you combine the two of them, you get a better model overall. Also important to mention their, there are different dimensions to structure the authorization models. So not just this one that I've just shown, but there are more dimensions, more criteria, more use cases that can those models be applied to. And each of the model has advantages and disadvantages.

So we have seen that for the aback model, focus on resources and the object disadvantages for scalability, for example, or the role explosion. We heard a lot about that.

Same for, for abec, it has advantages, there are disadvantages. If you combine them, you can provide a better overall authorization model. So the statements, the provocative statements probably for the, for the sessions for the session is each use case and we will get to back to that later, can be resolved by a certain authorization model or, and that is the second one by multiple authorization models. This is the idea of, of that session to give you a better idea of authorization models, the different authorization models, how we can use it, and how the future of authorization will look like.

And with that I hand over to David. Thanks, Phillip. All right. So just to quickly summarize what Philip and SEN have walked us through, really three things or three authorization models or three authorization phases, I should say admin time, very identity centric. This is where RBAC is gonna help us a lot. Where you define everything in terms of roles and groups and identities.

And, and to Philip and Sen's point, we, we don't wanna throw R back away, right? There's been, it's true.

You know, Philip, you were saying in the past EICs and even Iver, we tend to say throw away R back AAC is the future, right? Or or if you listen to Alex, Reba is the future, but actually we always need R back, right? So let's not throw it away. So that's the admin time piece with rback mainly is the model ACLS two. And then you have runtime authorization, which is what I focus on where you decide right there. And then when you need the access, you decide whether you're supposed to be able to get access to whatever it is you're trying to get access to, right?

And the main model in that world is abac. Reback as well.

Now, like as Philip and Y had pointed out, there's a lot of challenges with doing runtime authorization because you have to think about integration. And we'll see that in in the management slide. And then the, the third one that's really interesting that we've only just started talking about, I wanna say in the last year or so, is event time authorization.

The whole idea that if you're doing admin time authorization, we're at login, we're giving you some entitlement, some permission, some role, some scope, some claims maybe during the lifetime of that session you wanna say, Hey, that user no longer trustworthy. Or the other way around, hey, that user needs more stuff, let's send a notification and enrich their token or downgrade their token. And so that's where event time comes in. And we'll mention briefly later in some slides, things like CAPE and risk that are new standards from the Open ID Foundation to address event time.

So these are the three main things you wanna remember. So with that being said, let's look at how we manage authorization. So first of all, you'll, you'll hear a couple different terms, policy as code. You'll hear policy as data as a term as well. Policy as code is what I live and breathe every day. It's the whole idea that instead of defining authorization at admin time, instead of justifying a role and maybe entitlements and maybe scopes and claims in OAuth land, you can simply write a policy. And when I say write a policy, it could be written in any number of languages.

There are a few out there. Rego is probably the one that is the most widespread. It comes from open policy agent. And if you Google rego and, and opa, you'll find that it's, it's for infrastructure. It's true. But not only rego as a language can be used to define any kind of authorization language and any authorization use case.

I mean, and by the way, rego is so powerful. It can pretty much do way more than authorization, which is both good and bad. So developers love it 'cause it's so flexible. On the other hand, from a management perspective, from an audit perspective, from an edit and learning curve perspective, not so great. So you have other languages like CR like Alpha, and I'm, I'm the editor behind Alpha, so I'm biased of course, but it is the, the best, the very best language ever. It's pretty good. It it. There you go. Thank you. Andrew Alpha is constrained.

Cedar and alpha, they're both constrained languages. They can only do authorization, but they're easier to edit, they're easier to audit, they're easier to do access review. Either way, it doesn't matter. These are policy languages. What it means is that instead of expressing authorization in your application, in your, in your layer, whatever that layer may be, you're gonna express it as configuration. Ask policy, store that in a place. It could be a central place, it could be decentralized place. We'll talk about that later as well.

But at least you get visibility into what the configuration is. Just to compare that with admin time authorization at admin time authorization. When you use roles and groups, which remember we don't wanna throw those away. You have to write code in your app to be able to cater to the limitations, to overcome the limitations of RAC. I remember visiting an investment bank in New York many years ago, and that investment bank told us, oh, well the the way we do audits, you know, is when the audit team comes around, we just give them a screenshot of our application code. A screenshot.

Well, yeah, we don't want them to touch the code, we just want them to have a screenshot. Okay, what language are we talking here? C plus plus. Do they speak c plus plus?

No, they don't. So do they understand what they're looking at?

No, but you know, it's a compliance check. We, boom. Done. Right? Doing policy is gonna help you save that. So you could argue, if policy is so great, why would we wanna do policy as data?

Alex, do you want talk to this slide briefly 'cause you're the expert on, on Ad. Yeah, so there's another way to, shall I go there or? Sure. Here you go.

Well, I've got a, I've got a, Do you want stereo Alex, or Sure, I just want to point That's right. So there's another way to do access policies. That is to use data in a graph. Now I know it's kind of a newer idea, but you can model your graph so that you don't actually don't need to write code. The way this works is that in a graph, you will model your users or your identities and the resources you're protecting as well as anything else that makes sense to model for, for example, roles, but it could be locations or any kind of conditions.

The idea is then to look for a path from the subject to the resource. Like for example, here you have users, a couple of users, a couple of roles and a and some data that you're protecting. All you wanna do is follow a path in the data.

And you, and if you find that path in the data, then you can grant access. It's pretty easy. It's always the same, let's say policy always the same algorithm. You're finding a path. So what you change the is the actual data model. So why would you do that? You would do that because this is actually very easy to read. I bet you you can understand this much better than the Rigo in the previous slide. Yeah. What do you think?

Like, for example, can you tell me what, Bob, can you tell me if Bob can access the research data? Anyone?

Probably, right? So it's very easy to audit this stuff.

It's, it's really easy to approve things. And actually this type of stuff is what AI uses as an input. So if you have already your data in a graph like this, this is actually knowledge, it's not data anymore because everything is labeled.

So we're, we're shifting from data to knowledge quite an important shift. Hey, Sorry Alex. Yes?

Alex, What do you do about this? I mean, Sorry, thanks Phillip. What do you, that's great. It's very easy to understand. But how do you apply that? Like how do you actually then apply those rules?

Well, at runtime, all you're looking is for, say you wanna know if Alice can update this research data thing while you just look for that pass at runtime. So you use, if you use a graph database, for example, pass traversal or pattern matching is very easy, very fast. So you just say can find me a path between Alice and the research data. And if you find the path, then grant access.

Oh, yeah, Yeah. So That's, Yeah, I understand. I'm just saying, how do you actually then make, when Alice, how do you then configure that with your IGA or identity authorization System? Right?

Right, right. So you have to create the data. That's actually even for policy as code data, you have to supply data to those rules, right? So there's always going to be how do, how do you get the data to the policies here you actually create the data upfront. So you have like a, a setup phase where you suck in the data, depending on the tools you use for this. You can create the data on the fly through APIs or keep it updated through event streams.

So you basically, you have to keep that data up to date, which could be, or not a challenge, probably a, so Just, just I think your question's also high. Do you consume the authorization, right? Yeah. 'cause you see, I kind of understand Rigo better than this because I, you've got code there that does something. So I'm wondering how does this do it?

It's a, it's a, it's partly a matter of taste, right? I, I prefer policy too, but it's, it's a matter of taste.

With, with this is really good because it's graphical, no pun intended, right? A non-technical user can look at it and understand. And so this is just a picture, but if you look at the graphical interfaces of the tools that build graphs like three edges, you drag and drop elements and you link them together. So for a non-technical person, it's easier to consume. So Then if you wanna remove access, all you have to do is remove one of these relationships.

Yeah, yeah. The other thing that's worth mentioning is these are different ways to handle authorization, but to some degree it's behind the scenes. So there's two ways to expose that. The first way is the runtime, though you're building an app.

Thanks, I think I'm done with this slide. Let Me it down young man. There's more. Thank you very much. Round applause for Alex.

The, yeah, so to some extent think of this about, about being behind the scenes. At the end of the day, you're a developer, you're an application owner, you want to consume authorization. So you're gonna have to think in terms of how you send an authorization request and how you get a response back. So in my world, and I think Alice's world too, it's usually a yes no question, Hey, can I do this? And the answer is gonna be a yes I can, or yes you can, or no, you can't.

And so to, to help with integration, what we've been doing over the past year now is working on a new standard called Zen within the open ID family. And within Zen you have all the major authorization frameworks, open source and vendors, either policy based or graph based, or tuple based.

If you look at zabar, and we're exposing that standard interface, which means that you, when you're developing an app, if you wanna plug into a graph based product or a policy based product, which, you know, choose policy, then, then it's not gonna, you're not gonna be bound to that model because you'll have all zen to, to decouple yourselves from the underlying implementation. But one other difference, I can't remember if we touch on it later, but one other big difference that you alluded to, Alex, is where data resides in a policy-based system, you go fetch the data at runtime typically.

So if you need to know a user's department, you just go fetch it from a database and LDAP a rest endpoint in graph land usually. So three edges or open, FGA, you suck in all the data upfront. There's consequences on the architecture and the performance of the architecture and the, the liveness or the staleness of the architecture. But these are trade offs you're gonna have to consider later down the road. So going back to policies and policy management, what I use the word policy here, just think of it in general terms.

It doesn't matter if you actually use an actual policy language behind the scenes. There's different kinds of policies, there's technical policies and there's business policies. And what I mean by that is if you're gonna be protecting, say, an API slash medical records slash 1 2 3, you could write a policy in terms of technical terms, HTTP, get post, put delete, API query, path, query parameters, so on and so forth. Or which is, okay, great. And oppa is a great example of writing policies in technical terms, although there's nothing that forces you to do that in, in opa.

Or you could write policies in business terms. A user can view a medical record if they have a relationship to that medical record. A doctor can view the medical record of a patient that is in the same unit as the doctor, right? I tend to believe that if you can, you should always try to write business policies because at the end of the day, you're doing this largely for audit purposes, for compliance purposes, for reuse purposes.

So if, if you wrote a technical policy that is very API biased, then if you wanted to protect your database, you'd have to go back and rewrite it in, in database terms, right? So you don't want you, if you can try to do it for, from a business point of view, sources of policies within the, the enterprise developers. This is more of an efficiency use case. So we tend to think about authorization as a security mechanism to protect your apps or as a compliance mechanism, but it's also an efficiency thing.

If you as a developer do not have to actually implement authorization in your app, you're gonna save so much time. There was a report by a little company called Oracle 10, 15 years ago that considered that 20% of your time at the time was spent on security. So if you do decoupled externalized authorization, you're allegedly gonna save 20%. There's also application owners. These are the ones that care about the business requirements. Policy management tends to fall on their shoulders. There's the compliance team. They're gonna have company-wide rules about how you do business.

And then there's gonna be the legal team. I kinda separate the two, although it's a fuzzy line between, between the compliance team and the legal team. But generally speaking, if you care about, say, doing business with a country on the black list, you might wanna have a policy about that. So in terms of export control legislation, for instance, for anyone in defense and manufacturing, you cannot do business with, I dunno, Sudan for instance. Libya.

Libya, thank you. There's a, there's a few others on that list. Compliance tends to focus, at least in, in my mind, it's just a way to organize things. It tends to focus on internal things. For instance, Walmart will not run an AWS because these are two major competitors in retail. There's nothing legal or legal about it. It's just a business role. So some examples that you can think of, managers can view their bus, their customer's bank accounts. A customer can view their own bank account.

A customer can view the bank account of a child or a senior parent who's enabled to do banking on their own. Think also in policies that you can now define negative use cases in RAC and admin time. We give you things, we rarely can remove things from you. It's not like you log in and say, oh, I'm gonna remove that right from you.

Well, I didn't have to begin with, you're not gonna remove something I didn't have, right? But in AAC you can literally say, oh, if you're logging in from the UK and you had just logged in from Germany a minute ago, that's the impossible travel. We're not gonna let you do action X and Y. So you can have negative policies.

So before we decouple the authorization, the way that we would do policy or authorization configuration management would be hard because going back to my example of that investment bank, you'd have to go look in your user directory, you'd have to go look in the application, you'd have to make sense of that spaghetti code and try and pretend that you had a pretty good picture of what was happening within your ecosystem, right?

This is where you have a lot of the governance tooling being developed, you know, going back 15 years to try and address things like the join or mover lever process to try, try and address things like you've given employees entitlements and you wanna review those. So you do access recertification over time. The challenge with those approaches is that you don't always know what those terms mean.

You know, if a user has access to PR OJ dash one dash app three, what does that mean? You don't really understand.

And, and when you don't understand, typically you let the people, you let the employees keep their access and then you end up with access creep. Now, before we go into the, the management specifically, one more thing I wanna bring up is that we can pretty much authorize wherever you wanna authorize, right? It's decoupled authorization.

So if you wanted to apply authorization to your web layer, think SiteMinder or the, the, I was gonna say the newer products, I don't wanna imply that SiteMinder is old, it's true and tested, or the presentation tier or the API tier, all the way down to your app development layer, your business tier, and even your data tier. So you can, in principle, do authorization in any one of those layers. Going back to what you were saying, Philip, you know, the, some of the challenges between the RAC and ABAC is in RAC. You don't have to integrate in those layers.

It just happens through the authentication phase, which is very well understood. When you move to abac, either policy based or graph based, now you have to come up with a notion of an enforcement point that will do the interception at runtime for you. And you've gotta make it fit into one of those layers. So if you're dealing with APIs, that's easy. You have API gateways. But if you're dealing with a database, are we dealing with a database gateway? What does that look like? So these are things you wanna keep in mind.

Either way, you wanna make sure for the success of your authorization initiative, you wanna make sure that your enforcement and your configuration is loosely coupled from the app. Meaning that if you want it to change your authorization configuration, you should be able to do that very quickly independently of the app code and independently of the app technology as well. And you want to keep it that way. It's gonna help you bring on board more applications onto your authorization framework. It's gonna help you change your authorization requirements very quickly.

To give you an example, I, for the past four years I've been working at Salesforce, and now I just moved back into authorization. When the war in Ukraine started, I can't remember how long ago now, two years ago, a lot of businesses and governments decided to stop doing business with Russia. So the consequence for Salesforce was we can't let Russian companies log into Salesforce anymore. I ran the authentication team at Salesforce. What that meant for us is we had to stop logins from, from Russian ips, right?

You'd think there would be a switch somewhere in the code that says, Ooh, if IP is on this list, da da da ban, right? But no, we actually had to update the code and make sure that any IP coming in from Russia would be banned, right? Had we decoupled the authorization checks from the authentication experience, we could have done that without touching the code.

Alright, here's the lifecycle that you wanna walk through in terms of authorization management. The bottom line, the one key takeaway from this, from this cycle is think in terms of plain old English or fill in your favorite language. Even finish will work any fins in the room, alright? You didn't mean that French you or anything, but it's a very complicated language. Anyway. So the first thing, you wanna define the use case, very simple. And when I say define the use case, don't even think about authorization. Let's imagine that you're building a medical journal app or a banking app.

You want to talk about bank accounts and credit cards and amounts. You don't think about authorization specifically, but as you build your app very quickly you're gonna realize that yep, you do have some ti some kind of authorization requirements. It could be, in the case of banking, you don't wanna transfer more than so much per day. It could be that you don't wanna transfer to a country that you've not authorized payments to before. There's a lot of authorization requirements. But in step number one, focus on the application itself. Engage the different stakeholders as well.

The application owner, the business architect, the business analysts who have, they all have points of view. At this stage, you do not engage the compliance teams or the legal teams because you're not there yet. That brings us to step number two, gather the authorization requirements. If you're building a banking app, do you have to care about PCI or soc or do you want to care about ease of, of payment? To give you an example, I, I used to live in Sweden, which is why I made fun of the fins. I'm sorry.

There's a rule in, in Sweden you can do mobile payments between people in in Sweden, but there's a rule that says you cannot transfer more than say, 2000 kroners or 200 euros in a day. That's the limit that most banks have implemented as a consumer. You can go to your bank and say, Hey, I wanna change that limit. So the amount is changeable, but the policy is still there. You cannot switch as it's called, or you cannot transfer more than that limit per day, right? So these are your authorization requirements.

Another one would be, well, if you're a bank employee, you should not be able to view your relative's bank accounts at the bank because that's of either a form of nepotism or a form of conflict of interest that you actually want to prevent. And when you do think about authorization, the main hurdle that I've seen really is that people tend to think in terms of roles, right? Because we've been so used to thinking in terms of our back and permissions, we tend to say, oh, let me try to create the bank underscore manager branch role.

No, think in terms of plain old English, plain old, whatever your language think simple. That's really the main key takeaway.

Sometimes, you know, when I, when I talk to, to customers, they're afraid by authorization. It's actually quite simple, it's very straightforward. When you do that, you can define your attributes that are part of the requirements that you've defined. So you can actually highlight your attributes and you end up with a long table. So here in the purchase order example, we have throughout the slides, you can identify your purchase orders, their IDs, their country, they come from the customer, all of the metadata that will help you drive the authorization.

And the way to do that is I typically take a highlighter and I highlight the key words. So an employee that would be this subject can view, that would be the action, a record that's the object type. Or you're dealing with a record, a po, a medical record, a bank account. And then we have, just to make Alex happy here, we have a relationship in their own department. So you wanna digest that one a little bit and really say, oh, an employee can view a record if the user's department is equal to the records department.

Okay, one more thing. In the, in the management of policies, not all users are created equal, right? Some users are are very tech savvy, they're gonna be very good with policy as code. Other users are not as tech savvy. They're gonna be very good with graphical interfaces. There's different, there's a different set of tools out there that you can use at different vendors and different frameworks and different open source have. So if you wanna do for business users, you're gonna probably wanna focus on graphical interfaces. Three edges have a a, a pretty good one. Graph based.

If you're more for developers, then look at, at policy as code rego, alpha, cedar, oso. There's a, a long list of languages. Policy is still better though. But when you do manage your policies, when you do start defining your policies, do it in a way that reflects your business structure. What I mean by that is some businesses are very user-centric and they only deal with one resource a hospital has, medical journals, has medical results on so forth. It's pretty much just one resource, but different personas.

You have the non-medical staff and the medical staff, and with the medical staff, you have the doctors and the, the nurses and so on and so forth, right? So this is a very user-centric type of environment. One of my customers is, is a tax agency. Also very user-centric.

They have, you know, the, the tax auditor, the, the tax helpers on so forth. But all they deal with is taxes, right? So it depends on your business. Some businesses or the other way around, they have the one user and different types of resources. Bottom line is authorization configuration should let you reflect your business. I briefly mentioned, I didn't say orally, but on a slide I had written acceptance tests. For those of you who read slides, now is the, is the time to implement them as well.

And that's actually really important when you write your authorization policies and your authorization requirements. You also want to test your policies and there's different ways to do that. You could just do binary testing, you could do open-ended testing, you could do gap analysis testing. You can run those as a unit test.

So, hey, can I do this? Yes, no. Or as a batch test.

Hey, can I do X, Y, Z? Yes, no, no. But whatever you do, don't implement your tests at the last minute. Do it upfront. This is very much something that we, we borrow a page from the, the TDD, the test-driven design playbook, right? Don't consider that authorization is any different from writing an application. Think about your tests upfront. Do not let chat GPT generate the tests for you because chat GPT will generate tests based on what you've written. It's not gonna be able to test everything. You should be testing. Step seven, deploy your policies.

So that's very much bound to the architecture of your system. What does it mean to deploy a policy in a policy-based system? It would go maybe from dev test, QA, pro through A-C-I-C-D pipeline, maybe using GI ops as a principle to, to, to propagate the configuration in a graph based system. There might be slight differences to that approach, but probably GI Ops applies as well. As you do this, measure the impact on your app. So you've built an app, it works in one way, and then you deploy a policy. Does it still work the way you expected it to?

So not only do you wanna test, you know, going back to step five, not only do you wanna test the policies, but you also wanna test the impact of the policy on the app to see if it still works the right way. And for those of you following, I skipped step six. Did anyone notice? No. Is it too early on? Tuesday? More coffee. More coffee?

Okay, what day are we Step six. It's the architecture, it's the in depth slide. That's why I didn't repeat it. Think about where you wanna do the authorization that really, really really matters. And then one more thing. We've had a lot of good arguments over the, over the months and years about centralized and decentralized. So if you go back to say 2010, I would've argued that we want one single central PDP be it graph or policy today, thanks to open policy agent.

Actually we're realizing that well, hang on a minute, maybe you actually wanna have micro PDPs sitting alongside your application to do local decision making. At the end of the day, what really matters is the ability to externalize your configuration. Where you enforce, where you decide isn't all that important as long as you're capable of gathering all the audit logs that come from the authorization making process. And as long as you're capable of managing or at least auditing your configuration in a central place.

Alright, so speaking of auditing last step, step eight is run audits and access reviews. That is perhaps the coolest step you can do in the authorization journey and is also the one that is the most overlooked when you use an authorization system, an externalized authorization system, and you ask the PDP the policy decision point, Hey, can I do this or can I do that?

Or even, hey, tell me what I can do. That actually creates an audit trail of what people have attempted. And that audit trail is extremely rich. Not only does it tell you what access has been granted or denied, but it can tell you whether you're under attack. If within the span of a minute you see a million requests to the same resource by the same user, well there's something fishy going on there, you gotta go fix that. On the other hand, it might actually tell you that a feature of your system is never used. If no one ever tries to do X, maybe you don't need X. So use your logs.

That's like my, my call to action. That's, that's especially for my customers. It's use your audit logs. They're so rich, you can learn a lot from them. And if we wanna pepper in ai, 'cause now we need to pepper AI in a, in a bunch of places, then let AI learn from those audit logs and see what it can tell you about your authorization system. So with that being said, I'm heading over to Patrick.

Yeah, governance. Alright, thank you sir. Hello everybody. I'm Patrick. I have a bunch of you. So I'm gonna talk about governance and how, how the different models you choose for authorization impacts your ability to perform governance of access or whether it may pre presents a challenge or it fits hand in glove. So what is governance? From a first perspective, we come in my company, we come from a governance background and we've gone into the dynamic authorization market over a few years back like four or five.

So we, governance was always built into our thinking. So what is governance? Governance is the idea that you, the human and non-human identities in your system, that you can look at them and you can understand what they can do and you can measure that against policies to say is what they can do appropriate and and does it fall within the risk control of our organization. And how, and then also, how did they get this access traceability, what is the thing, the policy, the access assignment that's actually allowing them to do this action.

And in, in most systems that are out there, it's typically broken down into something. We might all use different names, but something called functions, we call it functions, SAP calls, it functions, other systems call it different things. But the idea is that you translating technical, very technical entitlements that no one really understands except the experts in those systems into human terms that your auditors can understand, that your managers can understand, that your end users can understand, and that has a risk associated with it.

So when you look at them and you see what they can do, everybody is speaking the same command and semantic the same language that that, that way you don't have to ev have be an expert in the actual technical entitlements. So looking at a user and knowing that they can perform, manage group memberships in an Azure tenant, they can do some basis critical actions in an SAP system. They can manage Kubernetes clusters, they can create purchase orders, approved purchase orders. Those are all examples of functions.

So characteristics of a functions, they should make sense to everybody, they should make business sense. So it's business language that's specific to your type of business and what you do. And they should classify the risk and they can be infrastructure type, they should cover everything, business activities, infrastructure, access, so that you can have a, a clear view across all of your different systems or policy engines. And they all, they almost all work the same way.

Basically your, your, you have your business processes, which is, you know, your sales process, your order to cash process, your various processes in an organization. And in those processes, people perform activities. I onboard a customer, I create an opportunity for that customer. And within those processes you perform functions. And then those, the, the, the key is to detect access, either access assignments in an RAC system, an ABAC system, a reback system. And how if, if you have those, which what does it allow you to do? Which functions do your access assignments grant?

That way you can figure out who can actually do which functions and how they got the functions. So the challenge with policy is code approaches on their own with no augmentation or enhancement by some other product is that first of all, they're in code that's very, that business users typically cannot look at and understand the implications of it. Second is they often are scattered, they're in GI repos, they're may be application specific GI repos. They're often not centralized in one spot. So they're all over the place.

So you can't really summarize what you have access to if the policies are everywhere in, in different code repositories as code. And a lot of the policies, even if they're aac, they all still use RA Cs y all mention group names or role names. So if you don't have a tie back to which of those are being used in policies and where that lives and which enterprise directory, then there's a lack of traceability here. So it presents challenges for people who are wanting to audit and understand the risk in an organization. This can be kind of like a black box that you really don't know what's going on.

So, and of course as I mentioned, each team who's developing applications, they might be have their own favorite flavor. They might be, you know, it's, so you might have some all kinds of different things scattered, OPA alpha, reback, rback all over the place and every team's doing something different and none of them are consolidating it all in one spot for analysis. So what do we do about it? So there's lots of different, well there's lots of different ideas. Right now there aren't that many great solutions or there may not be any great solutions yet. This might be, you know, future work.

So one idea is that you have one central policy administration point type of authoring system where you can author your policies. It has access to your enterprise data, your roles, your attributes, if resources, if it's resource centric, and it can output whatever flavor of policy you want to be in used at distributed policy decision points.

So you're, you know, you're cranking out strawberry, which might be cedar, you're cranking out vanilla, which might be alpha, and you're pushing it out to distributed policy decision points so that they can enforce the decisions, but centrally it's all in one spot. So you have a chance that understanding, analyzing it, auditing it, assessing the risk, and having governance, recertification of policies, risk assessment of policies, ownership of policies. So that's one possible idea.

And Jerry Bel at Strata, his idea is an intermediate language called IDQL, which basically can author policies and then have it transform them into native policies in various systems. That's, that's one idea. So Speaker 10 00:53:39 Can I just interrupt you? Absolutely. Speaker 10 00:53:41 Okay. So what you're really saying is, ideally what we want is the ability to create policies in, in a, in and, and save them in plain language or business language effectively. But the engine itself effectively doesn't produce code or X amount.

Well, it may produce it, but you don't see it. It's under the covers. Yeah. And effectively it could be OPA, it could be zal. Yep. Speaker 10 00:54:08 And so with no code, no XML, but you are saving it as, as I call it, or my CTO calls it named expressions business terminology. But everybody can understand and more importantly, anybody can run appropriate governance against you. Is that what you're Saying? That's one of three ideas. Okay. That's the first, that's the first second idea is that you let AI figure it out.

So I did some little tests, basically ai, you can tell it you're an expert in CER, you're an expert now for, you're expert in Rigo. So you can actually tell that it's an expert in these policies code languages, and you can feed it the policy data and have and, and teach it what is a function and have it spit out a consolidated view of what's the functional access that these PO code-based policies are granting. And then you could feed that into your IGA system.

So you could let them do native policy as code, feed it into a central system where AI crunches it and then normalize it into some structure where your, your risk system can understand it and manage it as functional access and traditional risk policies and point back to the policies code policy that was the source. Speaker 10 00:55:18 Okay.

I've got, I've got a question though. Yeah.

So in, in, in that case, I can see that has a lot of advantages, but my own company and my own focus is, is in the Department of Defense in a big way, huge areas.

And that's all about working on the five, the five eyes interoperability, mission partner environment where you want to do things which you, when you create policies, the policies in the Australian Department of Defense are gonna be able to talk to the policies, sorry, to your partners in the same effective language, whether that's EXACTL or OPA, but it's got to be something that they, they can understand when they, when that that policy is actually, you know, transmitted over a SAML authorization decision. It's got to be understand, understood at the other end.

But that's what, that's what the OEN group's doing because the policy, we're not transmitting the policy language, right? You're giving an endpoint where you should be able to answer any type of question using whatever behind the scenes policy engine you want, right? So you don't have to transmit policy, that's just everybody needs to be able to ask a question in the same format and get the same formatted of, of an answer back. Correct.

And then you can do whatever you want behind the scenes as long as that, yeah, Speaker 10 00:56:36 I mean, I keep coming across solutions vendors, whatever out there in the marketplace that haven't 40 through properly. Yeah. And they don't, it doesn't work properly.

I mean, I I I, I don't, I won't name names, but I've got Speaker 11 00:56:50 A classic case at the moment. I don't think I need, well, Speaker 10 00:56:53 If you want, I've got, I've got a loud voice, so I've got a sound loud voice. Okay. Is it loud enough or the online attendee? Yeah.

Oh, I'm sorry. Speaker 11 00:57:00 I apologize. It's okay. I'd forgotten about the online things.

So, yeah, so I, I suppose I've lost the train of thought here, but I'm sorry. The, a lot of this sort of discussion go is going on with, you know, the five eyes with the on, in NATO in nist, US government, DOD or whatever, about how do we ensure that we've got interoperability that, you know, you know, from on the battlefield, you know, between talking to, you know, a submarine, you know, where when we are passing, you know, squirting data a a short amount of data, we've got to be able to do things in a consistent way and it's got to be a capability that we can both understand.

So, Yeah, and, and I, I think the US government has done a lot of work in policy-based environments, especially back in the day of Zol. Yeah. But still today they've defined profiles.

So it it, the work that data was not so much on the policy language at the time. There was only zl, so that was a given that probably needs to to change. But they did do profiles to define what attributes to use. 'cause one thing is the policy language, but the other is agreeing on what word you're gonna be using. 'cause you call, you could call it UUID username, whatever it may be. Or resource type object type. Like there's different ways to describe things, right? So what the Yeah, it's the schema. Exactly.

So what the FBI did in the past, what VA veterans Administration did in the past was defining those profiles or those schema so that we all speak the same, like doubly same language, right? So I think there's probably more work, Andrew, that we need to do in that. Speaker 11 00:58:32 And, and you're absolutely right. I mean the, the, the, the common NATO standard for attributes and are very clearly defined actually in ACP 1 33 edition D schema, which is widely used across all of nato and it actually defines all of the attributes in some TD and the profiles.

And, and, and that's how that it, we ensure currently and, and to be truthful right now still nato, the fire vice, it's all exactly based. But the point that's been missed, I think is that the important thing is policies absolutely must be business statements that people can understand.

No code, no XML, That's my number three. So this is probably going to make me not very popular here, but number three and, and come find me if you want to see it. I made a quick spike just for this workshop. It's not product of an LLM policy decision point. So in the L-L-M-P-D-P you can author your policies as human sentences. Like literally Bob cannot do this unless this and the L and the LLM can be, you train it to be an expert in OPA Rigo C auth then even. Exactly. Exactly. Yeah. So basically it can accept in anything they want, any way they want to ask it.

If they want to ask it via, you know, so some o zen or they want to ask it in human languages, can so and so do so and so it can ask be asked in any format and it can answer in any format. So, and it, it, it, I mean it is just a spike. It's not meant to be a product, but it, it seems to be pretty interesting, interesting proof of concept. If you wanna come by and see it, I'd be happy to show it to you.

So I have to interject one thing here because all of these are limitations of policy as code as you guys expressed, but as I alluded to, policy as data provability and auditability is right there from the start. So you don't need to do anything else, just look at your data. So that's also, that's one of the great benefits of it. And even in the LLM model. But most in the future, a lot of the graph data is being integrated in the L-M-L-L-M via the rag retrieval augmentation.

So even in this model, you still might be authoring your policies as data in a reback system, but talking to it through an AI interface and it could be pulling multiple data sources. So it, I just think we're at a point of disruption where you need to rethink everything with AI in mind. Definitely. Okay.

So that, I think I am now we are onto case studies are back. Okay. Case studies. Case studies. So we're gonna go through some case studies about typical. So as we mentioned, not every option or model is best for a best fit for every scenario. So we're gonna talk about case studies and we have our, our purchase orders scenario where you have an application that's somewhere in its database, NoSQL, sql, some data source, it has purchase orders, and they have individual purchase orders and they have, you know, attributes or columns about 'em. And I was given the R-A-C-R-A-C use case.

So one in my RAC use case, one misnomer about admin time versus runtime. Everybody says RAC is admin time, but that you all policies are defined at admin time, abac, everything's defined at admin time. The question is, will, and all of the types of models can be asked questions at runtime. Even in RA system you can do has access to see if I'm trying to approve a purchase order, five, can I do it? So every system can be runtime. The question is do the, can the results vary at runtime and an RAC system at runtime, it's always gonna give you the same answer.

ABAC system you pass in contextual data and everything else. So it might give you a different answer, but all systems can be realtime runtime systems.

That, that's a, a misnomer to say that some are and some aren't. So in this RAC model, VE is assigned a role that role grants the right to view and approve purchase orders. And he has assigned the role directly to an individual purchase order record or to a folder that contains the purchase orders. Traditional, you know, RAC inheritance model.

So this, this, just like reback, one thing to mention is a typical RBAC system, you need the data. When I'm in the policy administration point and I'm defining a policy, it's not abstract. I'm not saying purchase orders where country equals this. No. You literally have to have the data, you have to be able to say, I wanna sign access to this purchase order or to this folder of purchase orders. And that's the difference between system systems that have the data versus policy systems that are just about attribute questions where they don't have to have the data.

So if you have a system with like, let's say a hundred billion invoices, you probably might be leaning toward an ABAC solution. Whereas if you have a system with like your key privilege credentials or something like that where they're individual and you wanna control who has access to them, you might be leaning to more of like an RAC reback type of scenario. So that's basically, that's, that's my shtick on that. I'll hand off for alpha to David. Sure. So it's pretty simple. It's the same use case. I think the, the, so it's, it's policy as code of course.

So you, you can re oops, go back to policy as code not graph. I think the slides have a conscience of their own.

Anyway, the bottom line is you can pretty much all read this. I know that Alex always says it's easier to read a graph and you know, a picture is worth a thousand words I guess. But here all we're saying is we're gonna create a namespace policies live inside of a namespace. I have a policy here that focuses on purchase order. Great. Okay. And then I'm gonna have two sub policies here. One about viewing a purchase order, the other one about editing a purchase order. And then here that little line is determining how those two policies are gonna get combined together, if at all.

So in this case I'm saying, hey, whichever first policy gives me a decision is the policy I'm gonna keep. Okay, great. And then if I'm gonna see the detail of view purchase order, this is what I have here on the right hand side here, I'm looking at the action that the user is trying to do.

So view, and then in this particular case, I'm just, if a user wants to view a po, I'm just letting them view the po. But then I slap on a negative policy here. And essentially I say if the user's id, I made a typo, it should be user country is equal to PO country. I need to learn how to write alpha.

I know, I know. Embarrassing then did I, right?

So yes, sorry about the mistake in the policy. It all works, believe me. And then here you could have one about editing.

And I, I didn't put any particular checks or the, the decision you could build out to say you could only edit a PO that you own, for instance, or a PO that is in draft mode in that you own so and so forth. So that's alpha in a nutshell. One of the key benefits is that you can quickly read it, write it, deploy it, store it wherever you wanna run it. And it works with GI ops.

So yeah, Alex. Yeah, thanks. So this is what the same use case would look like in a graph and graph policy as data approach. So as you can see, this is data. We have four times the same kind of thing. We have the four users in orange, and then we have the things that trying to access in, in yellow here. And there's you basically looking at the path from the user to the things that trying to access. So everyone user has two ways to access the things, right? One goes through the role. So that means it's possible to access the resource if you are an approver.

And one goes through a location, for example, here through France. So what we wanna do is we look at both actually to enforce the condition we want to have to see both paths. If a user is missing one of those paths, then we're not granting access pretty easy. And as you can see, I can prove this anytime. You could just look at the data and prove that it works and it's always there. So any questions about, so I'm gonna keep going. The future of authorization, that's me. So it's for The future.

Yes, My slide, sorry, didn't mean it that way, but yeah, sorry. Enough.

Anyway, it's really hard to predict the future, right? But at least the future is grounded in the present. So we can already kind of see some of the things I'll be talking about and yes is pretty obvious. So the first thing is that we will start, you know, basing our authorization on real time events. This will happen more and more often because we are in a highly dynamic environment and things happen in real time, especially if you're concerned about zero trust, we'll definitely need the real time events.

Thankfully we have, you know, the shared signals framework with, with an OpenID that provides a couple of standards right now that will help us cap and risk events. And I'm expecting this to, you know, keep going and we'll see more and more of that. Another thing that Europe is actually spearheading a lot, right? It is verifiable credentials. And there are already use cases where, for example, you know, a, a bank advisor, a financial advisor can only access bank accounts with certain values or certain conditions.

So anything that is based on the credential could be used, you know, for authorization. Like, and, you know, kind of call it VC back 'cause very credential based access control.

Oh, anyway, so we will see more and more of that. And I'm waiting to learn here at the IC more about it as well. And Alex, if I can double down on that, the fact that we have a lot more data today to play with, and the fact that we have a lot more trusted data, especially through verifiable claims, is gonna create a whole lot of opportunities.

So today, if you're an EU citizen, you know, and, and you walk from Germany to France to open a bank account in France, like the experience breaks down because the French don't trust you. But tomorrow, because of VCs and because of established trust between the, the countries, we're gonna be able to do that. So we're gonna like authorization and, and, and having more identity data is gonna help us create better consumer experiences. So it's not like authorization is not just negative use cases, it's positive use cases.

You don't agree, Speaker 12 01:08:55 You're not suggesting you can change the minds of French people using, I'm French, I'm French, Just I'm here talking about it. Just bring cheese and spaghetti. So Here's an interesting use case about this. Like we've seen a use case in a, a company that has cruise ships, right? Cruise ships are very certified environments like either the captain, the seafarer, the engineer and whatnot. Well guess what? They can use VCs now to get access to stuff on the ship.

So any, what another one is IGA, like Patrick alluded to that you'll see that there'll be a, a merging of IGA authorization. Like especially if you externalize authorization. Now your authorization system is going to be the best place for you to do IGA because it knows who has access to what, right? So you'll see that there's gonna be a merger of these two functionalities and the external authorization system will become the IGA platforms Or vice versa. Sure. As long as you can define policies in your IGA system graph adoption. And we see that a lot already.

Now I've alluded to it, but a lot of companies are using graphs like the big ones name, many of the big ones. They, they definitely have a graph like we see that in banking, insurance and, and a lot of other places. And the shift there is that now a graph is really knowledge because you use a labeled property graph, you're actually using knowledge and you'll see that knowledge is the thing of the 21st century. Last century we used data, now we will use knowledge. So I'm expecting this to grow. Yeah. Do Speaker 12 01:10:32 You make a distinction between knowledge and information?

Well, as long as you can attach semantics to your information, then it's knowledge. I guess you need semantics, like meaning essentially. And for that you need labels and an understanding of how the labels relate to each other. Let's called an ontology. Yeah. Speaker 12 01:10:53 Have a separate Discussion. Sure. So Speaker 12 01:10:55 Are you saying that whether it's meaningful, sorry, you understand the sentiment of when you can action it. Maybe if you take that data and turn into function, then you have knowledge.

Speaker 12 01:11:10 Sorry, the question I was gonna ask, sorry, apologies Speaker 11 01:11:12 Interrupting you. Are you saying that we basically need access to the metadata relating to the information as part of the process? Is that what you're saying?

Yeah, you need, yeah, essentially the metadata being the label. So in other, in other words, once you yes, sure answer would be yes and but not only that. And how does that metadata relates to each other? Like for example, you know, users and cars, how do they relate to each other as concepts? Speaker 12 01:11:42 Here where you say knowledge union semantic. That's right. That's right. Yeah. Speaker 12 01:11:49 So semantic interoperability. That's right. And which leads us to ai because actually AI uses knowledge graphs to input data.

I'm talking about this later this week. But anyway, AI is hard to tell where, where that will go. But what we can see already, a couple of things that we can see already. One is the rise of AI assistance and I know Microsoft has been demoing last year at identifiers, a cool feature of copilot. You can answer, you can ask AI any questions, you know, what can Ali do? Or I've got a new user, I've just hired somebody, can you please grant them the right access? Stuff like that. So you already see the beginnings of that and we'll see more and more of it.

Something else that you already see is AI to fight ai. This is quite popular in the ID proofing world where you have ID proofing companies that already use AI or neural nets to identify deep fakes or liveliness. And we'll see more and more of that. And I'm looking forward to implement that for authorization as well.

That's, that's all I have on this front. I mean, I'm sure there's other things and wish to know where AI will lead us. There's one more thing on the future of authorization. Do you wanna say a couple words again about sen? Oh yeah, right, of course. Should I mention, David and I are part of the odds and working group within OpenID and we're working towards doing protocols and standardizing a lot of things so we can interoperate so you don't have to be locked into with one vendor or, anyway, makes things easier.

Speaker 11 01:13:20 Hopefully that would solve my, That that should definitely between the five eyes. Yeah, Andrew, there's, there's a session I think on Wednesday about Zen and there's another one on Friday. So if anyone wants to hack on Friday, there's a, like a mini Zen hackathon Friday morning. But apart from that, there's a couple of panels and sessions on Zen throughout the week. Thank you. Did it?

Yeah, with that we get to the transition strategy. So one of your questions could be, well they, these guys are talking about a lot of theory here, how can I apply that? So at least that was my first take of that. It sounds a little bit theoretical to be honest. So that makes the transition strategies much harder. But in the end it comes a little bit down to, to a roadmap. So questions that, that are in the room are what is the status quo of my organization? How can I describe that? Do I need to do everything from scratch? Do I need to renew everything?

But in the end, it's really how do I move forward at all? So what is the next step? How do I get to, to graph based authorization models or the alpha language? What is that? So how do I get there to do that?

I, I first of all need to understand where I am and where do I want to be in the future. And this is where you open up the gap. So you can see that here, this is how you open up the gap to understand how to move from A to B sounds very simple, but it is not, to be honest. It's really important to understand in terms of authorization strategies, what you want to, to do in the future, right? So we have not much time left, so I will speed a little bit up. The idea of step one, the status quo is really to get a good overview of what you have.

And it's not just about authorization models because we could all say, Hey, we have ABA in place, we have abec in place, and that's fine, but it does not really help us. We need to connect use cases, different applications and the used authorization models. So that makes basically a matrix where we have the use cases and the roles, the description of the use cases, and I've, I've just filled in some examples here. Time tracking an application, maybe a SharePoint, you name it. And then in the columns, you, you add the information that you have.

So basically what authorization model you are using for that. This is a status quo. Very simple, it's just assessing what you have. The target state is to identify where you want to go. So what are the authorization requirements that would be working best for, for that use case? And it's not always a, honestly, you cannot re, you cannot solve every use case by aec. I mean you can, but it's not the best way I would say. So we have different stuff like the time tracking that everyone has that has a low risk. It's probably centralized. So I might want to use an ABE approach.

We have an application, so fair enough, that is Abe probably, it's it's owner driven. It, it is done centralized. That could be a perfect IGA tool use case, right? But there is more out there and you want to identify the best authorization model for that use case. Step three, filling in the gap. So I have identified where I am, I have identified where I want to go. So I need a plan to get there in the end. And this is the change aspect. So how do I change from one authorization model to the next? I look for a look out for clusters.

So I want to tackle them by authorization model clusters so that I can move forward, use case by use case. That is basically the idea. So next question would be how do I assess all of that? So what are the criteria that I apply? And for that I used the, the presentation that Alex gave, yeah, last year. So referring to that, you can, you can see that online, I have the reference here on the slide. When you think about authorization models, they have advantages and disadvantages.

And these here are the criteria that you can apply and that help you to match your use cases to the, to the authorization models in a, in the best possible way. So you can investigate which use case, which authorization model, what are the criteria that I require and that are working best for my use case. That brings us to the following slide. When we think about organizations, and this is sort of simplified idea of it, we, we think of different kinds of access. And on this slide you can see four clusters that I, I have designed just to describe an organization.

So an organization can have multiple different kinds of access. For example, company access. That means that there is simple access, basic access that everyone has, and that is of very low criticality. So that would mean that everyone can get that automated very easily. Second cluster is organizational. That means every kind of access that is granted based on your organizational attributes. So if you are part of an organization, if you are part of a team, you will probably get that access in an automated way.

Usually those, those critical, the criticality of those excess rights is in the low or medium area. So not highly critical. You can get that probably without any kind of approval. When we think about the third cluster, the functional cluster, this is where it usually gets complicated. And this is also a large cluster. So they are not of the same size. The functional area is really where the business is doing the day-to-day work.

That means that we have all kinds of criticality in that it could be low criticality for a read write, there could be a medium criticality for, for a write, write or there could be a high criticality for, I don't know, sensitive data. But that means that we are, in terms of scalability and, and in terms of provisioning, we are a little bit limited here. So you cannot provide all of that on an automated way without approvals. You probably need approvals. Not everything can be applied at runtime, at admin time.

So this is a very heterogeneous cluster where we probably hit the limits of, of automation at a certain degree. Last cluster, on the right side, we have the special cluster. And this is really the access that only one or two people in an organization will, will get like a, a privileged access is, could be in there, or c-level access is in there. So we have a very, very small group of people that get that special, special entitlements or special special access in an organization. So why am I trying to tell that?

But what I'm trying to say here is when you see on the bottom line, the further we go, right, in the clusters, the higher risk and complexity is, is the risk and complexity for those kinds of access. On the other hand, the, when we think about company and organizational access, the scalability requirements and the assignment range or the assignment range is very high. So a lot of people will have that kind of exit, but the scalability will be low, the scalability requirements will be low. So you need a lot of scalability there, right?

The idea in the end is to find the right authorization model for each cluster. So left side is more on the automation and of the authorization models, focusing on scalability on the assignment range, providing access to a lot of people because the ri the access is not very risky, not very complex right side. It's exactly the opposite thing. So very high risk, very complex. Only a few people in the organization, organization will get that kind of access. That's the idea. And we are running out of time. So let's get to the last chapter.

Conclusion for transition strategies here is that there is not a single authorization model that can, that fits to every kind of use case. I was saying that in the beginning, in the first chapter, the idea is really to combine the different authorization models to make it work, to make everything work to will not resolve the whole authorization landscape by a single authorization model. Speaker 10 01:23:14 Can I ask you, can I ask one, one question?

Speaker 11 01:23:17 Yeah, Speaker 10 01:23:18 I think I, I certainly, I know the answer, my Speaker 11 01:23:21 Perspective, I know the answer, the, but the question I've got is, do we all accept that that authorization should be externalized from the application? The reason I'm asking this question, it's pretty basic, but Yeah, but I mean, I, but I'm, I keep coming across software companies that have actually adopted aac, but they've adopted AAC in their application. IE they have not externalized the to a, an external policy engine.

I'd like your views as a, as a group as to is that a good thing or is that a bad thing? And if so, why?

I, I, I, I've got my personal view, but this, I'd like to ask the question. I think it's okay, but it depends what we mean, right?

If you've, if you've given the ability to externalize the configuration so that you can audit the configuration and do access reviews, then it's fine. Right? Your app or your, your SaaS or whatever it may be, does not have to make an external call to an external PDP If the PDPs embedded within the app, that's okay. As long as the configuration is visible, accessible, and auditable.

That's, that's the main driver that you wanna achieve, I think. Oh yeah, you're right.

It's, but it's considerably harder to audit and to know who has access to what, when that those policies are spread out all over the place, typically in black boxes that the apps are. So that's the why externalizing makes Governance challenges. That's right. Still each one's its own little island then. That's right. Yeah. Speaker 11 01:24:53 The Speaker 10 01:24:54 Reason I ask the question is, I was, I was staying with somebody over the weekend in Belgium Speaker 11 01:24:59 And they told me, skip it.

They told me that in the hospitals in Belgium, they're all adopting a, a c alright, as a, as a context. But they're doing it in their application, in their healthcare systems in because they don't have any need for interoperability with other people. But they like the concept of making authorization decisions in their environment as a, as an internal capability and not externalizing it only, no policy engine, external policy engine, et cetera. So that's The reason one confusion.

Half the customers that come to me and say they're looking for abac, what they really mean are dynamic attribute roles to automate people in dynamic attribute policies to automate people into static roles, which is not what we're talking about here at all. But half of them, that's what they mean by abac. Speaker 11 01:25:49 Yeah. Okay. And that's, I knew the answer, but I wanted to Yeah. Hear you Guys, but, but that's been the challenge over the years.

I, I mean I've personally kind of given up maybe, maybe we'll be more hopeful, but commercial software vendors externalizing authorization. I mean, I even Salesforce doesn't do it. Microsoft doesn't do it. I-S-A-P-I haven't seen anybody do it and I haven't seen any drive for them to do it. It would be nice, but I, I've kind of given up hope on that.

We're, we're trying to change that throughout then I hope, hopefully we'll get There. That's, that's the hope. Yeah. It's gonna take some time. Speaker 13 01:26:23 There's a couple of issues here, is that abstraction is a really important part of our architectures. So we very good at locking some of our systems together, making them one of the reasons why some vendors who have already solved the problem would like to be able to keep that proprietary information of how to do it. So there is no reason why they should abstract it so that everyone else can share from that benefit.

But that's an important part of lifting this stuff so it's independent and you can have this authorization layer, which can span all of the different systems that people can subscribe to outside of the implementation of the resource that you're using. That's where we really need to get to. Yep. And it will take some time. So we just need to get on with it.

It'll, I just think it takes a willingness. I don't see the willingness to do It. Hopefully we'll get there. Anybody. Yep. What do I get there? Speaker 14 01:27:40 Well, I think there's another, another two other dimensions.

If you, if you're centralizing, everything gets more complex. The more parts you put into a centralized model, it's gets more and more complex and you will more arable occur more where you will have more bucks. Since you can't over have an easy overview of the architecture when on definition, time and when you build it. So there might be a size where it's right to do centralization, but centralization, but it won't scale up to infinity. That's one thing. And for the next parties, it, if you do a lot of centralization, it pays off in, in aspects of resilience.

And especially if you have critical systems which you want to access in a crisis or something like that, then centralization is counterproductive. Then you've got to get at least in, into some offline run ability of offline running or something like that. And you've got to go for design of resilience. And that's, that's, that's why we, we've changed the definition of centralization.

You know, going back to 2010. We centralized the PD DP in the decision making, which we theoretically is true. And you can still do that today. But I think the requirements that you just gave and OPA have shown us that you can have any number of PDPs co-located offline.

Like any, any architecture, what really matters is the decoupling. And then you choose what you want to centralize. If you wanna centralize decision making.

Sure, but you gotta, you know, you gotta think about what you just said. Right? If you wanna centralize just the management Sure. Or if you want to decouple the management. 'cause different teams write policies at different paces for different purposes. You can do that too, as long at the end of, at the end of the day, you have visibility and auditability into what you've been doing. That's where centralization really, really matters. Yeah. The architectures nowadays.

Yeah, you, you have all kinds of distributor architectures that are possible. Yeah. But most of our customers say they do not want us in the runtime. Mm. So we may offer the policies, but they don't want us to be in the runtime. So if it goes down, if we go down that anything is affected. So that's where you get this distributed PDP model. We have maybe centralized authorization, centralized policy administration and governance with distributed enforcement, distributed decisioning enforcement. Anybody else? Yep.

Oh, okay. Speaker 13 01:30:00 I think we have a little bit of a problem with the semantics of what centralization means.

Yeah, yeah, yeah. Speaker 13 01:30:07 We've got a knowledge problem. Tell me about it. I think it's more, as David said, is essentially essential to decouple and then how you architect your essential pieces is another question. Good. What do we do around conclusion? We have no time left. So That was it. I Think. Good q and a. If you have any questions, just ask us. Thanks Phillip and Yassen for hosting us and keeping us more or less on track. Yeah. Thank you for being here. Thank.