Unleashing the Power of Modernized Authorization

Welcome everyone to our KuppingerCole webinar, Unleashing the Power of Modernized Authorization. The speakers today are Gal Helemski, she's co-founder and CPO, Chief Product Officer at PlainID, Allan Foster, who is identity expert on behalf of PlainID, and me, Martin Kuppinger, I am Principal Analyst at KuppingerCole Analysts. This webinar is supported by PlainID. Before we start, I'll do a little bit of housekeeping.

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 will discuss the results during the Q&A session. There will be a longer, I would say, discussion on the Q&A session at the end of the webinar, so you can enter questions at any time, specifically in that part where Allan and Gal and me will talk. We will also pick up questions if they really fit into this, and we are recording the webinar.

We will provide a slide I can record soon after the webinar. As I've said, we will run a few polls during the webinar. The first one is here.

So, that 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. Are you planning to shift to policy-based access control or access management, PBAM, as the model of full authorization, so away from traditional models that, for instance, build more standing privileges, static entitlements?

And the options here are no current plans, only for selected areas like in building new digital services, something you're currently planning or something you already feel you have, you know, sort of in use on a broader scale. So, looking forward to your responses, and I would say I give you some 30 seconds or so. And for all the webinars, the results are way more valuable the more people participate, so don't hesitate to enter your perspectives. We leave it open for another 10 seconds or so. Then 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, Gail will talk about navigating modern authorization and kick-starting the PBAM or PBAC, the Policy-Based Access Management, Policy-Based Access Control program. And then Gail, Alan Foster, and me will go into the discussion, which we will mix with the Q&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 and try to give our perspective. So, for my part, I took a bit of different approach than I usually do. I prepared 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 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 kick-start 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 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 margin, can take an action, access to an object, a file, during work hours, constraint. And the structure is always the same. At the end, the firewall policy, which is more about IP addresses, ports, basically has the same structure. Policies have the same structures. Constraint 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 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 must not underestimate.

So, policies are here. We are using them day by day, not just in IAM, everywhere.

So, it's ubiquitous. We have firewall policies. We have authentication policies, very widely used 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 we say, okay, Martin is in this department. Because of that, he will get these access entitlements, policies, building access, cyber security policies.

Okay, some of them are not as good as they could be. Not always consistently.

First, if you have authorization policies, and yes, oops, we had XACML here. 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. If environmental, social, et cetera, governance policies, export control policies, everything is 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 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 trust picture, it's not far away from that. It is something which works. And the problem is that it's 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 must underestimate. Applications where we bake policies in the code are very, very hard to govern. It's a problem we have. We can't discuss about it.

It's just, at the end, something we really can't have. No, 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, OPA. In developing modern digital services, the open policy agent, OPA, has become quite popular. It's a bit different.

So, we have users that want to access resources, components like applications, databases, et cetera, to some API-based access through a service mesh, all API-based. And then we have the open policy agent. And this is queried, all standard JSON and lean. And that uses a policy store and a 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 is the, then here we are around the decision point, et cetera.

So, it's not fundamentally new. And we are administrating this.

So, at the end, 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 them. The charm I see in policies is really that policies are so simple to describe and to understand. That is something which is really easy. You 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-consuming things, from a business level to a very technical firewall, et cetera, policy. If we manage these policies and use them consistently across everything, then we can change things very easily, and we don't bake it anymore somewhere. We do it in 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 obvious, obviously more efficient. And as I've said, policies are also at the core of zero-trust architectures.

So, when you take the neatness zero-trust architecture in a nutshell, then this is about a subject with a device going to a resource as a policy enforcement point, back to this terminology, a decision point, an administration point. So, there's the control plane, where we control who is allowed to do what, and there's the data plane, where we execute things from untrusted on the left hand of the PEP to trusted on the right hand of the PEP.

And then there are systems helping by providing information, 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 ton of information used to minimize the risk in access. But it's at the core, it's policies.

So, if we say 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 must not end up with a policy model for our digital services here, and for digital services here, and a policy model here for firewalls, a policy model for our legacy applications, a policy model for authentication, etc. 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 design. I would even dare to say, if you don't do it policy-based, then you inevitably fail in security by design and privacy by design. I know it's a bold statement, but think about it.

So, we have the policy life cycles, governance, the data governance, but then we implement it sometimes a bit faster, sometimes a bit slower, also depending on what policy allows. 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 management, identity governance and administration?

So, all these ugly static entitlement things, this recertification and so on, we all have probably experienced. Is it about policy-based access controls and API security? Or are other or none of these areas? Looking forward to your responses. And with that, I'll then hand over to Gail for the second part, navigating modern authorization and kick-starting the PBAM program.

Gail, it's your turn. 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 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 in 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 there for 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 authorizations. Authorizations 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 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 research, or a other type of information.

Again, anything we know about that can be part of our policy. The when can be 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, 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 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 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 there ready to use. We just need to define the standard and use them and let our teams, our development teams, engineering teams, deal with the business logic they need to work on.

So, that's one very important impact 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, authorizations 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 zero trust 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 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 Plain ID 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 done via an accounts portal, which uses APIs to access the different resources.

So, API 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 Plain ID 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 the product and what does it mean, modernized authorization policy management. Policies are expressed in a graphical way, a business-like manner way, very clearly identifying the who, the what, and the when. But they are also supported in a code-like manner. This is fully Lego-based to enable both the business and the development engineering to collaborate on managing and using the authorization policies.

So, just to summarize everything I said, what are customers doing in regards to modernized authorizations? So, customers would be looking into modernizing of their technology stack, maybe building new application, portal, 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 organization, 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. So, how are customers doing that?

Well, PlaneID has a solution to offer to support all of those patterns, providing central control, visibility, consistency, and standardization. And lastly, 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 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, Gael, 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 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 ForgeRock, where I had 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 love it. I think we know each other for decades.

So, the point, I think we probably walked really through these questions, and the first one, it's a very generic one, the first talking point, that is about what are the challenges of modern identity management. I'd like to expand it a bit, and, Gal, you touched a bit on this already. Why is policy-based access, policy-based authorization, why is this the answer to that?

Maybe, Alan, so Gal and me have been talking. Your perspectives first. The first perspective I would put into it is that, in terms of policy enforcement, we know how to do it, right? You brought up OPA in yours. We've had policy agents around 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 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 crufty because people start doing new jobs, and they have new things, and various things like that. So, one of the things that policy gives us is that, and I'm going to 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.

And so, 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 policy, right? It's really, it's going to be correct next year or two years from now.

Yeah, and I think this is a very good point because, to make another bold statement, I think the root cause of all bad identity management are standing privileges, static entitlements. Because the problem is, when we have something, we write into a system and say, okay, this is the ACL, the access control is 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 roles, when we develop entitlement structures, we think about policy what do we do there? And even when we then transform it into something static, it's decoupled. And if it's decoupled, then it's hard to track. That's why we have this recertification. I think I never have met any organization globally where the people said, hey, recertification of access, this is what my departmental managers would really love to do. Never.

Yeah, for sure. I absolutely agree with both of what you said. I just want to emphasize another thing.

And, Ellen, for sure you touched it. Policies express the reason, the logic.

I mean, 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 authorizations 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? You're certifying, you can then certify the logic, the reasoning for the access. Yeah. And I think one important point also is that a lot of stuff we do with policies is at runtime. So we have to policy and at runtime, we check the policy and make a decision. While in the static world, we have authorizations, at the end, we also have a runtime analyzer. So we look at the ACL, but the ACL, as I've said, is decoupled. So it's not necessarily 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 we have a deploy 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 most of the traditional concepts with a policy syncing, we also lack the option to automate. So if we would have, and we have legacy systems. So if we still need 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 be at least close real time. And so that we move closer to something which is really more runtime sync than a deploy time sync. I think 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 got to 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 really, this is why we have to have access certifications, is because we know that access control gets crusty and old and people move and they no longer apply. So we constantly have to come back and clean it up and bring it current again. I would like to argue that policies are not just for runtime. Because runtime is obviously the goal.

We want every decision to be there as accurate as possible and as fine-grained 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 talked about separating management, decision, and enforcement. I truly believe in that. It's okay to still enforce using even ACLs, whatever we choose to do. And we can still manage those by policies. Policies are good. They are efficient in management. They express the logic. They are 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. At least maybe I said it, but I didn't mean it. But the point is exactly, we can use policies to automate what is, so to speak, static. 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 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 is some boring piece of work in that, in developing, so to speak, the playbooks, 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 will extend this question, best part of policy is the automation of sort of attributes 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 take on this? I think that the governance and the administration, the 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 last slide that Gal 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 and 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. Gal?

No, I have absolutely nothing to... Okay, then I play a bit the advocatus diaboli. I think that there's...

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 define 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 yes, I think a lot of companies and people have managed to have too many firewall policies and other stuff. That is a risk. I think for me, but anyway, this is something we can get a grip on. I think we can also get a grip on very good on testing approaches. So how does a policy finally impact something? That is really not rocket science to my perspective. The thing I found most interesting is another one, that is from a governance perspective, a policy. So in contrast to static entitlements, a static entitlement says, Martin has this access.

And we can say, this is what we see here, because it 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, there's 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 data governance piece. This is something which is overlooked, but there are tons of tools out for data governance. We don't start from zero here. We can bring these things together. We can bring it together relatively easily.

And yes, we need good data, but that's doable. Yeah, I agree. But I also want 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 I want to share my opinion. I don't think you need to start by cleaning your data.

I mean, it's always the chicken and the egg, right? By the time you clean your data, you already have done so much that maybe policies are not, you kind of missed the opportunity to implement the right authorization solution. You need to do those in parallel. We are all familiar with those IGA 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-grained. Your decisions won't be as dynamic. 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 you want 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. 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 a member of an AD group called AD underbar US underbar something. 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 Garl'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're 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 underlying data is also most cases ugly and icky.

Yeah, but I think you're both making a very important point here. And I don't say that you need to have all data perfect. I think over 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. And for a lot of the data, you will have it anyway. And 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 so also the entitlements we have aren't.

So it's not that it's getting worse, but we need to keep it in mind. We need over time. We need this thing to come together. And that brings me also to another question which came in from the audience.

That is, are there tools that can help bootstrap a PBAC approach from existing RBAC or by examining AD groups, nesting, naming conventions, et cetera? I could imagine we have a bit different perspectives. My perspective would be we could do that, but I never was a believer in role mining because my experience is 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 do agree with that because policies enable you to capture much more than just the individual assignments role are designed for. It enables you to capture the broader decision rather than just the identity perspective. So if we look at what are roles designed for, they are 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 need to always duplicate the access which they are providing. That's one of the challenges and one of the core reasons we have role 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 a short sentence, so that we can go through a couple of this. The first one to you Gail is, does Blaine ID support a mining approach to bootstrap PBAC 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 PBAC implementation at CM, Consumer Identity Management Environment. What about the customer experience impact to policy application? Ellen. I think it absolutely fits, because 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're 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 lot of different things based on the same policy. I would also say perfect fit. Yeah. Okay. How to transition to modernized authorizations, how to get started, Gail? How to get started, pick your low hanging fruit, a new application that is focused on business objective, provide authorization as a service. That's how you get started. Start small, start focused 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 Ellen, you start then Gail and I may also comment it. Do you think PBAC can completely replace ACLs? Probably 99% of it. I think there's always going to be sort of the weird exception where it's, this is the policy except for Allen. But I think in 99.9% of the cases, PBAC policy ends up winning over the individual. Okay. Gail?

Yeah, I absolutely agree. I think they can replace the majority of assignments to identities. Always individual assignments are needed. Those 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 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 denying the dynamic binding sets of entitlements to identities. So a trust in time provisioning, so to speak as a dynamic binding could be easily done in IGA tools. With relatively little effort and should work quite well. We did it in SAML, for instance, at the end of today. A bit bumpy, but we did it. So why not using things like that? So before we stop, a quick highlight.

I won't display it just in the interest of time, but for the polls, for the first polls, roughly 45% said they don't have current plans. 45% are planning and the remaining roundabout 10% say we only look at PBAC 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 IGA, so to speak. And we have a bit of responses also to policy-based access controls and API 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 time for this webinar, which brings me to saying thanks. Thanks to you, Gal, for all the insights. Thanks to you, Alan, for your insights. Thanks to Blaine and I.D. for supporting this Coupling 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-based access. Thank you.

Thank you, Martin. Thank you.

Thank you, Martin.