Unleashing the Power of Modernized Authorization

Welcome everyone to our Kuppinger call webinar, unleashing the Power of Modernized Authorization. The speakers today are Gail Ky, she's co-founder and c p o, chief Product Officer at Plain id. Ellen Foster, who's identity expert on behalf of Plane I and me Martin Kuppinger. I'm Principal Analyst at Kuppinger Call Analyst. This webinar is supported by BLA Addie, and before we start, I'll do a little bit of housekeeping and first Paul, and then we directly dive into the topic of today's webinar. So audio is controlled centrally, nothing to do from your end.

We will do two polls during the webinar and if time allows, we'll discuss ourselves during the q and a session. There will be a, a longer, I would say, discussion on q and a session at the end of the webinar. So you can end the questions at any time and specifically in, in that part where, where Ellen and Gal and me will will talk, we will also pick up questions if they, they really fit into this and we are recording the webinar. We will provide a slide I can recording soon after the webinar. As I've said, we will run a few polls during the webinar.

The first one is here, so, and that is a, is one which is a bit ahead of what we are discussing today, but it might be something where you say, I have it anyway in mind. So looking forward to your responses and this is, are you planning to shift to policy-based access control or access management PBA pbam as the model of false authorization. So away from traditional models that for instance build more in standing privileges, static entitlements.

And the options here are no current plans only for selected areas like in are building new digital services, something you are currently planning or something you already feel you have, you know, sort of in, in use on broader scale. So looking forward to your responses and I would say I give you some 30 seconds or so. And as for all webinars, the results are way more valuable than more people participate. So don't hesitate to enter your, your perspectives. We leave it open for another 10 seconds or so. I think we can slowly close the poll and then look at the agenda of today's webinar.

So the agenda is split into three parts. The first part I will share some thoughts about the power of policy-based authorization. In the second part, gal will talk about navigating modern authorization and kick-starting the P B M or p a, the policy-based access management policy based access control program. And then Elle Ellen Foster and me will go into the discussion which we will mix with the q and a. So we will talk about various aspects we see from our professional experience around policy-based access as well as we will pick any question you enter for this discussion.

I'll try to give our perspectives. So for my part, I took a bit of different approach than I usually, usually do. I prepared my, my thoughts a while ago and I still felt this is the best way to explain it on a whiteboard. So it's a bit like when I think about topics, I attempt to to scribble these things on physical paper, on whiteboards or on virtual whiteboards. And that's what I did here as well.

And I hope this gives you some sort of kickstart of around thinking about policy-based access and some of my perspectives, which might be right or wrong, surely something which will also be part of the discussion later on. So first the point is policies are something which is which are well understood, a common concept. They are easy to understand, they have a standard structure and that is what I really like with policies. So policies are something which is a subject.

Martin can take an action, access to an object, a file during work hours constrained and the structure's always the same at the end. A firewall policy, which is the more about IP addresses, ports basically has the same structure. Policies have the same structures. Constrained can be complex, they also can be used for some sort of nesting. So we have a lot of things we can do. Policies can have relationships for sure. So Martin for instance, there might be a building access policy, a computer access policy, a firewall policy, and many more with at the end relatively complex relationships.

But all of these policies for themselves are rather simple. And sometimes we can derive high low level policies from higher level policies. So we have a business policy that is about whatever access of certain things only during work hours that might may impact multiple policies. It's simple, it's straightforward. That's why I like policy. Everyone can express a policy child don't touch the hot oven. It's a policy, subject action object from real world policies are ubiquitous. And this is I think a point we, we must underestimate.

So policies are here, we are using them day by day, not just an IMM everywhere. So it's, we have firewall policies, we have authentication policies very widely used in, in, in, in, in, in, in, in identity management. So based on the authentication, based on the risk and other things we allow access or not. We have segregation of duty policies, we have birthright provisioning where where we say, okay, Martin is this department. Because of that he will get these acts, entitlements policies, building access, cybersecurity policies, okay? Some of them are not as good as they could be.

Not always consistently first if we have authorization policies and the as, oops, we had exactl here, if you, it still lives in some areas, but we also have a lot of means to do it more so let's say a bit leaner, more efficient, et cetera. But we have the policies and it's everywhere. Zero trust. This entire zero trust model is built around policies. We have environmental, social, et cetera, governance policies, export control policies, everything as policies.

And yes, we had this sort of traditional model authorization policies. We have a policy decision point, policy enforcement point policy information point administration, represent repository point. So all of these things, and this is still something which at the end in some way works quite well. And at the end when we look a bit at the zero draft picture, it's not far away from that. It is something which works. And the problem is that is only that we don't use it enough. I love externalized authorization because then we have a policy and then we change the policy, the logic changes.

What we do today frequently is we write code and in that code we say what happens? So we sort of bake a policy into code. This is something we, we must underestimate. Applications where we bake policies in the code are very, very hard to govern.

It's, it's a problem we have, we can't discuss about this is, is this at the end something we, we really can't have? No we, we need to make it available. And the best way is to do it in a consistent way with policies. We have a new way here also O P A in developing modern digital services. The open policy agent O P A has become quite popular. It's a bit different. So we have users that want to access resources components like applications, databases, et cetera. It's an a p I based access through service mesh, all a p I based. And then we have the open policy agent.

And this is queried all standard chase and lien. And that uses a policy store and the data store, oh by the way, the policy store could be the policy repository point, the policy information point is the data store, the policy agent does the, then here we are around the the decision point, et cetera. So it's not fundamentally new and we are administrating this. So at the end it's, it's a bit a different picture. But again it's about saying we have someone who manages the policies easy to describe, very clear and we can use it.

The charm I see in policies is really that policies are so simple to describe, to understand that is something which is really easy. We can explain it in natural language, we can do it very lean and we do it everywhere. We are used to it.

And yeah, we have policies everywhere from a very high level to very cost granting from a business level to a very technical firewall, et cetera policy. If we manage these PO policies and use them consistently across everything, then we can change things very easily. And we don't bake it anymore somewhere in we do IT policies, we also don't do it as configuration settings somewhere in an application. We do it in a generalized way, in a central way. This is very OB obviously way more efficient. And as I've said, policies are also at the core of zero trust architectures.

So when you take the need this zero trust architecture in a nutshell, then this is about a subject with a device going to a resource. There's a policy enforcement point back to this terminology, a decision point, an administration point. So there's a control plane where we control who is allowed to do what, what. And then there's the data plan or the plane where we, we execute things from untrusted on the left hand of the p e P to thrust on the right hand of the P E p.

And then there are systems helping by providing informations like authenticating the user and doing things like that and other systems that also help in verification, providing signals that we can use to ensure that we have a a ton of information infused to minimize the risk in access. But it's at the core it's policies. So if we say zero trust, we must yes to zero trust, we must say yes to policies no other way. What we need to understand this is my final point here is we need to start this the right way to my perspective.

So at the end we, we must not end up with a policy model for our digital services here and for digital services here and a policy model here for firewall, a policy model for our legacy applications, a policy model for a syndication, et cetera. We need common concepts such as life cycles governance, but we need different speed of implementation. So we need a multi-speed approach. So the conceptual work, looking at standards, this is something which is central and we will end up with better software because policy-based access means security by design and we can do privacy by the design.

I would even dare to say if you don't do it policy-based, then you inevitably fail in security by the design and privacy by design. I know it's a bold statement, but think about it. So we have the policy lifecycles, the governance, the data governance, but then we implement it sometimes a bit faster, sometimes a bit slower also depending on what policy laws. But let's bring all these policies, silos or avoid creating policy silos. Think about policy as a holistic thing in your IT beyond identity, beyond security. Think big here. But authorization is a key element in that.

With that, I come to poll number two and that is where do you see the biggest potential for policy-based access control? Is it the authorization service for digital services? Is it replacing role-based access control in identity measurement, identity governance and administration? So all these ugly static entitlements things with recertification and so on, we, we all have probably experienced is it about policy access controls and a p i security or are it other or none of these areas? Looking forward to your responses.

And with that I'll then hand over to GA for the second part, navigating modern authorization and Kickstarting the p m program. Gail, it's your turn.

Yeah, thank you. Thank you Martin. So thank you for covering authorization policies. So well. I'm going to focus primarily on why do we need authorization policies and then the how of implementing those authorization policies. So let's start with why we need authorization policies. So as you probably know, authorizations are all about connecting identities to data, to digi digital assets. Those are authorizations.

So if we look at the identity and access management space, the majority of the space up until now was focused about, was focused in BI managing identities, authenticating identities, and we have many solutions in that area. And the question now is what should all those well-defined identities? Well authenticated identities do, I mean they're therefore a reason. And the reason is to access data, to access digital assets, whether those are bank accounts or insurance policies or medical records or files or whatever. That's the reason for all those well-defined, well authenticated identities.

And that is authorization. Authorization is the, is the part of identity and access management that answers the who can access what and when a modernized authorization solution would do that in a secure, simple and extendable way, which is part of the reason we are here today. So how do you ensure security simplicity and extend extensibility? And the answer is by using well-defined authorization policies. So let's look a bit more in depth into those authorization policies. So I'm going to repeat a bit of what Martin already mentioned.

Authorization policies is about managing the who can access what and when. Very structured, very well-defined. Any authorization policy has those three elements. It has the who all the subject it has, the what or the object or the asset and the when, which are all the conditions associated with that type of access. The policy is basically a combination of those elements expressed in a business like manner, in a way which is understandable also by the business owners, not just by the more engineering part of the organization.

So a policy can be, for example, account managers can access accounts in the region or medical researchers can access their own research data or nurses can access the medical information of their own patients. Okay? So those would be your authorization policies. And as you can see, they combine elements from the who for example, the who title and the location like the account or in the operating in the us in the uk, in Germany. So that would be the who part.

They include elements from the what, the what would be financial accounts or it would be medical res medical research or other type of information. Again, anything we know about that can be part of our policy. The one can be a elements like time of day or location or any other conditions, constraints. We want to put on that access that is today the most efficient way, again, as Martin expressed and known to be supporting the management of those authorization policies.

So we now understand authorizations is what connects identities to what identities wants to access authorization policies are the way to manage those connections identities to digital assets with all conditions. And the next question is why, what is the impact, the business impact of using a modernized system such as, such as that to manage authorization. So we see three main impacts that are associated with a modernized authorization. The first would be enabling the modern business.

And, and let me explain a bit about that. So think I would say 10 or 15 years ago, we still didn't have well-defined authentication in place. If we wanted to build a new application to implement a new solution, we had to develop authentication Today nobody would even think about building their own authentication process. It's a well defined standard and many well defined matured solutions are providing authentication as a service. And the same goes for authorization.

If we want to move forward faster with any business initiative, we don't need to spend time on authorization the same as we don't need to spend time on authentication. Those are their ready to use. We just need to de to to define the standard and use them and let, let our teams, our development teams, the engineering teams deal with the business logic they need to work on.

So, so that's one very important impact author modernized authorization has. The second is obviously associated with risk and security. Eventually authorization is the way to control what identities can access and what they cannot access. So that ties very directly into your security, your overall security posture. Remember authorization control your identity, security posture. That's the way it is defined. That's the way it is managed.

That's the way you can control, that's why you can see the zero trust as a main, as one of the main factors that contribute into adopting modernized authorization solution. And the last part, we decided to put that as a separate one because it is so powerful and that is secure access to data. If you look at any initiative, any digital initiative that you have eventually at the end of the game, data is there, even if we're thinking about modernizing our applications or implementing new strategy for microservices, APIs, whatever those are all means to access data.

Therefore the secure access to data is so much important to consider and to be, to be supported by a modernized authorization solution. So those are really the three main drivers and where we see the most impact of a modernized authorization. How the next question would be, okay, we understand it's important we understand what it does, but the next question would be how, so I do have two slides that speak directly to plain id. Plain ID is the authorization company. We have an authorization, a centralized authorization platform supported as a service in the cloud.

On one side it provides all those management capabilities, Martin mentioned in order to support efficient management of authorization policies, lifecycle management, investigate reporting, and so on. But then all those well-defined policies should be then enforced well across the technology stack. And for that we have what we call plan authorizers, which is a set of technology specific components that support the enforcement of those authorization policies.

If we look back at one of the examples, let's say account managers can access their accounts, maybe that access is, is done via an accounts Porwal, which uses APIs to access the different resources. So a p i access control is in play. And now our authorization policies are enforced through APIs or microservices type of deployment pattern. But then we might also have a reporting system that looks at the same accounts. So then we want to enforce maybe authorizations in Power BI or in Snowflake or Google BigQuery.

So remember Martin was saying policies, they have a logical structure, a business-like language, and then they have their specific localized interpretation in APIs, in microservices data and so on. And that's exactly what the plane a platform supports. It supports the central management of those authorization policies with distributed enforcement across technology stack.

And then just a quick view into a very brief view of to into the product and what does it mean, modernized authorization policy management policies are expressed in a graphical way, a like man way, very clearly identifying the who, the what and the when. But they are also supported in a code like manner. This is fully regular based to enable both the business and the development, the engineering to co to collaborate on managing and using the authorization policies. So summary, just to summarize everything I said, what are customers doing in regards to modernized authorization authorizations?

So customers would be looking into modernizing of their technology stack, maybe building new application Porwal and so on. Maybe they are in a zero trust initiative or they have some data initiatives. Those would be the main drivers for modernizing authorization policy. So if you have any one of those initiatives within your organizations, you should consider the authorization question, how can you better and faster implement any one of those using authorization? So those would be the projects why customers are doing that.

So it ties right back into the main business drivers either enabling the modern business, reducing the risk, and tightening security or secure access to data. Sorry, how are customers doing that?

Well, plan ID has a solution to offer to support all of those patterns providing central control, visibility consist consistency and standardization. And lastly, how the, how the authorization platform supports all of this. What are the main deployment or use cases, patterns, and that goes right back to applications, APIs, microservices and data. So starting from the business initiative, the, the, the driver for implementing modernized authorization and then going all the way into the how and the technology that supports that. Thank you. Back to you Martin.

Thank you gal for the insightful presentation. We also can finally welcome Alan here on camera. Here we go. Great.

Alan, a pleasure also to have you here. Thank You very much. We already have a couple of questions here, a couple of talking points, and so I think we, we, we will directly dive into it. So maybe Alan, you introduce yourself quickly before we jump into the conversation.

Well, hello everybody, I'm Alan, and for those of you that don't know me, I have been involved with identity for probably the last 30 years, most recently with Forge Rock and where I had the, the job of identity evangelist, which means that all of these topics we're talking about are near and dear to my heart. So thank you very much for having me here.

Yeah, and that's, I I love it. I think we, we know each other for decades now. And so the, the the point I think we, we probably walk really through, through this questions and the first one, i i is a very generic one or the first talking point that is about what are the challenges of modern identity measurement.

I, I'd like to expand it a bit and g you touched a bit on it this already, why, why it's policy-based access, policy-based authorization. Why is this the answer to that? Maybe Alan Lan may have been talking your perspectives first.

So the, the first perspective I would put into it is that in terms of policy enforcement, we know how to do it right? That you brought up o p a in, in yours. We've had policy agents around for, for 20 or 30 years in general, we know how to enforce policy. The challenge that we have is maintaining the correct enforcement over time.

It's, it's management of ensuring that over time the right people still get to the right stuff. And invariably when you start looking at access control, it gets old and crafty because people start doing new jobs and they have new things and, and various things like that. So one of the things that policy gives us is that, and, and I'm gonna say something here that's a little bit weird about it, is that it distances it from the identities. It basically says here is the policy and when you need to enforce it, have a look at the identity and see if it matches. Yeah.

And so it it gives us a way to be able to ensure that the correct policy is enforced over time. And we don't look at that when we start looking at at policy, right? It's really, it's gonna be correct next year or two years from now.

Yeah, and I think this is, this is a very good point because yeah, to make another bold statement, I think the root cause of all bad and identity management are standing privileges, aesthetic entitlements. Because the problem is when we have something we write into a system and say, okay, this is the a c l, the access control list here or whatever, then we write it there, it's in there and it says, Martin has this access to this whatever folder on a Windows file server. And it's decoupled from where it comes from. And we do it even in a way that we don't think about. There's a policy behind.

So we do it, there is a policy behind, but rarely when we develop roads, when we develop entitlement structures, we think about policy to what do we do there. And even when we then transform it into something static, it's decoupled. And if it's decoupled and it's hard to track, that's why we have this recertification. I think I never have met any organization globally, but the people said, Hey, recertification for access, this is what my departmental managers really love to do. Never Yeah, for, for sure. I absolutely agree with, with both of what you said.

I just want to emphasize another thing and, and delan you, you for sure you touched it. Policies express the reason, the logic, I mean we, we are, we do need some specific assignment, personal assignments to identities, but eventually, if you're working within the organization, the reason for you to being able to access something is because of the job function or other organizational considerations that are associated with yourself. And that's exactly the policy.

The majority of authorization's decisions are because of the function you play within that organization and then they tie to what you can actually do and not because you are person X or person Y. And that's the strength of the policies, their ability to express the logic. And then it ties back to what are you certifying or certifying. You can then certify the logic, the reasoning for the access. Yeah.

And, and I think one important point also is that a lot of stuff we do with policies is at runtime. So we have the policy and at runtime we check the policy and make a decision. While in the, in the static world, we of authorizations, we at the end we also have a runtime analysis. So we look at the A C L, but the a c L as I've said is decoupled. So it's not necessarily the, the most current thing. If we change the policy, we need to transform it into an updated access controls or whatever. And this is where, where, where we have a deployed time element in.

So we need to deploy in contrast to just the runtime. And then also with the fact that we don't start for, for most of the traditional concepts with a policy thinking, we also lack the option to automate. So if we still would have, and we have legacy systems, so if, if we still need this, this run, this deploy time element where we say we need to write it down there because they don't support anything else. If we don't start with a policy, we can't automate that change as efficient as we would need to, to beat at least close real time.

And so that we move closer to something which is really more a runtime thing than a, than a deploy time thing. I, I think you, you actually bring up a very valid point there as well. And that is when we start looking at acls, ACLS are a snapshot in time.

It is, you know, who can access this resource right now? And in order to change acls, you've actually gotta go back in and change them. And very often the reason that a particular identity has access to some resource tends to be very distributed. It may be because a VP over there somewhere has said, for this project, Alan needs access to this. Or maybe it's because Alan's an employee or maybe it's because he lives in Portland. And so somebody who's responsible for controlling an access control list doesn't understand the reasons why somebody was given access with policy.

You've got a reason and we don't care that Alan has access or not. As long as Alan meets that reason, then Alan gets access to it and it means that we can make it much more dynamic over time.

And, and really this is why we have to have access certifications is because we know that access control gets crufty and old and people move and they no longer apply. So we constantly have to come back and clean it up and, and bring it current again. I I would like to argue that policies are not just for real runtime because, you know, runtime is obviously the goal. We want every decision to be there as accurate as possible and as fine grain as possible and dynamic as possible. But the reality is that's not where the majority of customers are.

And we shouldn't restrict the usage of policies just to the end game. We should, I mean we, we talked about separating management decision and enforcement. I truly believe in that it's okay to still enforce using even acls, you know, whatever we choose to do.

So, and we can still manage those by policies. Policies are good, are are, are, they're good. They're efficient in management. They express the logic, they're relevant regardless of the way which you enforce. I absolutely agree you want to be as dynamic as possible, but I don't think that can always be the case.

No, not what I said meant at least, yeah, maybe I said it but I didn't mean it. Yes, but the point is exactly, we can use policies to automate what is, so to speak static.

We, we don't leverage this potentially yet, but we bring in artificial constructs like roles instead of saying we have policies and we have a means to automatically translate a policy into the access controls we've done, right? This would be way leaner for instance, than roles. And the other thing we, I think we didn't as an industry care enough about is how can we translate higher level policies into lower level policies. There are a lot of higher level security policies that we could automatically translate in appropriate firewall settings or whatever to a very low level.

This is yes, there's some boring piece of work in that in developing so to speak, the playbooks, the, the, the patterns of what translates how. But I think there's a huge potential here. And then we have exactly this, we can support everything, but we start with the policy because this is the logical point to start.

However, and this is another question I'd like to pick up here that is, and I also to extend this question, best part of policy is the automation of sort of attribute driven changes. A few challenges pop up with this, the complexity. So if you have a lot of policies, the evaluation process, the what if impact analysis. So when things change, I would add the governance, the governance I believe is of policies is an interesting element here.

So Alan, you're already nodding, sorry to disturb you from drinking coffee. What's your PO take on this? I I I think that the, the governance and the administration that sort of sort of go hand in hand and one of the things that policy gives us is the ability to have a policy enforced across many different points of access, right?

If the, the last slide that Gaal had up there shows access control or policy enforcement at the web tier, at the data access tier and possibly even other tiers and all of those end up, it sort of, it comes back to your model of this governance. Very often those tiers are managed by different people, possibly even in different organizations and policy gives us a way to be able to propagate the same reason down to all of the different methods of access.

Yeah, well No, I absolutely agree nothing to, Okay. Yeah.

Then, then I play a bit the avocado, the Aly, I I think there, there's so, so yes, I think one thing is like we have role explosions and other things, there's a risk of policy explosion. I believe we can handle that well when we, well this define a, a policy governance, a lifecycle model and different levels of roles and how they intersect, how they are related to each other, et cetera.

But, but yes, there, there, there I think a lot of companies and, and people who have managed to have too many firewall policies and other stuff that, that, that is a risk I think for me. But anyway, this is something we can get a crib on. I think we can also get a crib on very good on, on testing approaches so that, how does a policy finally impact something that is really not rocket science? To my perspective, the, the thing I found most interesting is, is another one that is from a governance perspective, a policy.

So in contrast to static entitlements, a static entitlements is Martin has this access and we can say this is what stand, what's what we see here. And we can say this is okay or not. A policy says subjects are allowed to do something under certain constraints. And that is where not only the policy comes in, but also a lot of attributes at runtime come in. So during work hours when accessing from the system with this context risk, et cetera. So we use data during the execution of a policy. And so we have a sort of a policy governance aspect and we have a data governance aspect.

My belief is that what we need to ensure is that the data we use to make this decision, these decisions must also properly govern. So we need to look not only at the policy governance piece, but also at the data governance piece. This is something which is overlooked, but there are tons of tools out for data governance.

We can, we don't start by from zero here. We can bring these things together, we can bring it together relatively easily and yes, we need a good data, but that's doable.

Yeah, I, I agree. But I also want, you know, a word of maybe caution here because sometimes that's what makes organization consider if even to go in that direction. Organizations are staying in the path of roles, overusing roles just because they believe they need to start by cleaning their data. And that's a very, very tedious operation. So want to share my opinion, I don't think you need to start by cleaning your data. I mean it's always a chicken and egg, right?

By the time you clean your data, you already have done so much that maybe policies are not you, you kind of missed the, the, the, the opportunity to implement the right authorization solution. You need to do those in parallel.

We all, we are all familiar with those i g a projects that started with cleaning data a year later. You need to start all over again. Start with a modernized authorization solution regardless of the data you have. So your decisions won't be as fine grind, your decisions won't be as dynamic. Yeah. But you will have the solution in place. And then once you clean your data, your decisions would be more dynamic and more granular and what everyone them to be. But don't wait for having all your data in place, cleaning all your data to start using a more modernized approach for authorizations. Hello.

I would absolutely. What do you think? I would absolutely agree, right? One of the challenges we've got with data is we have using the data for reasons that it was never intended to be used for. And when you look at traditional role-based solutions, right? When we look at a role-based solution, almost none of the roles that we use for access control are actually roles that we use in the organization.

It's, it's a member of an ad group called AD underbar, us underbar something. And, and that role is not something that we use. And so we've taken this idea that says, oh, well people who do the same thing probably need the same access control. And that makes sense from a role-based, we realize that we don't have an attribute or we don't have a role like that encoded in the underlying data. So we make one. And that's why, as you pointed out, Martin, we end up getting 125,000 different roles, one for each different application. And to the most part we've no idea what they do.

And so going back to GA's point on this, you can scrub that data, but that data is actually shadow data to the actual organization. It's data that we are keeping in place to try and mimic the organization so that we can enforce access control. And if we simply look at it from a perspective of policy and say these are the people that should access in, it actually makes that problem easier and simpler. But you're right, the the underlying data is also most cases ugly and icky.

Yeah, but I I I think you're, you're both making a very important point here and I I don't say that you need to have all data perfect. I think all time. You need to understand which data is used and to ensure that you have proper governance, proper processes around the data ownership and all that stuff that, that is.

And for, for a lot of the data, you will have it anyway. And to be, to be very clear, it's not that we could say, Hey, when we look at an average role-based approach after a couple of years, we all know that usually isn't in the perfect shape. Let's phrase it friendly.

And, and so also the the entitlements we have aren't so, it, it's not that it, it's getting worse, but we need to keep it in mind. We need over time, we need this, this thing to come together. And that brings you to another question which came in from the audience that is, are there tools that can help bootstrap a ppac approach from existing r a or by examining ad groups, nesting naming conventions, et cetera? I could imagine we have a bit different perspectives.

My my perspective would be we could do that, but I never was a believer in role mining because my experiences that role mining tends to preserve mistakes we've made in the past. And I also believe that the policies can be derived way easier top down than any type of role-based or static entitlement model. So it's way leaner to do that than any role model. My perspective.

Yes, yes, absolutely. I I do agree with that because policies enable you to capture much more than just, you know, the individual assignments role are designed for. It enables you to capture the broader decision rather than the just the identity perspective. So if we look at what's the role of identity of, sorry, what, what are roles are designed for, they're designed to assign something to the identity. They take the identity perspective. If you are a manager in the UK or if you are a manager in Germany or in the us, that's what they capture.

But because of that, because of what they capture, they it, they need to always duplicate the access which they are providing. That's one of the challenges and one of the core reasons we have world explosion today policies, they don't have that problem because policies capture both what we want to know and understand about the identity and also what we want and we know about what the identity is trying to access in a single policy statement. You can capture all of that.

Okay, so we have quite a number of questions coming in here. So what I propose for the remaining minutes is I raise a question I say to whom you provide a one sentence more or less answer short sentence so that we can go through through a couple of this. The first one to you gallers does explain Id support a mining approach to bootstrap a by discovering and analyzing entitlements across the enterprise. So we have that as part of our professional services.

Yes, part of our professional services capabilities. Okay. Curious about pbe implementation, cmm consumer identity management environment. What about the customer experience impact to policy application? Ellen? I think it absolutely fits because if, if we think about it, it's actually defined as being less important about individual identity attributes and more focused on what is it that we are trying to do. And so in the consumer space, most of the consumers end up being can this consumer do this or can that consumer do that?

And so I think defining policy for that actually fits really, really well. And the dynamic change of consumer experience can be based on the same policy as the data that is displayed. So we can do a ton of different things based on the same policy. I would also say perfect fit.

Yeah, Okay, how to transition, transition to modernized authorizations, how to get started GA l, How to get started First pick your low hanging fruit new application that is focused on business objective, provide auth authorization as a service. That's how you get started. Start small, start focus with something which is as ready to use as possible, then grow from there. Okay. I think the final question here I'd like to pick is, and maybe Alan you start girl and I may also comment. Do you think PBA can completely replace acls? Probably 99% of it.

I think there's always going to be sort of the, the weird exception where it's, this is the policy except for Alan, but I think in 99.9% of the cases PBA C and policy ends up winning over the individual. Okay.

Yeah, I absolutely agree. I think they can replace the majority of assignments to identities. Always individual assignments are needed. Those are true, should be treated as exceptions. I think exceptions should be exceptions. Not the majority, not the main path, which is what's happening today. I personally believe ACLS will be here around around for maybe not ever but for decades. But I think what we can fix to a 99% is managing ACLS without using policy.

So I think we can shift this entire thing with relatively considerable effort to policy-based control, even about the areas where we still need to rely on things like that. For instance, by deny the dynamic binding sets of entitlements to identities. So a trust in time provisioning, so to speak, with the dynamic binding could be easily done in i g A tools with relatively little effort and should work quite well. We did it in SAML for instance, at the end of the day, a bit bumpy, but we did it.

So why, why not using things like that. So before we stop a, a quick, quick highlight. I won't display just in the interest of time, but for the pulse for the first pulse, roughly 44 5% said they don't have current plans. 45% are planning and remaining round about 10% say we only look at PBE currently for selected areas. For the second poll where around the biggest potential. We have also a bit of a tie between authorization services for digital services versus the next generation of I G A so to speak. And we have a bit of responses also to policy-based access controls in a p i security.

But everyone has an area where he or she says yes, there's a huge potential for that. So we're at the end of the time for this webinar, which brings me to saying thanks, thanks to you GA for all the insights. Thanks to you Alan for your insights. Thanks for to Blaine ID for supporting this copy and call Analysts webinar. And thanks to everyone listening to this webinar, hope to have you soon back in one of our upcoming webinars or events. And happy to always, I think every one of us always support you with all your questions around policy best access. Thank you. Thank you, Martin. Thank you.