Modern IAM builds on Policy Based Access

Welcome to our KuppingerCole Analysts webinar, Modern IAM Built on Policy-Based Access. Today, I will talk about some of my perspectives on why and how we can sort of modernize the way we manage access to applications, to systems, to services, using policies and getting rid of some of the challenges we commonly face when you're built on traditional approaches like RBAC or Role-Based Access Control. So I'm Martin Kuppinger, I'm Principal Analyst at KuppingerCole Analysts, and this webinar is brought to you exclusively by us, by Coupling Call Analysts.

So before we start with the webinar, a little bit of housekeeping. There's not much to say. Audio is managed centrally. We will run two polls during the webinar, and if time allows, we will discuss the results during the Q&A session. We will do some Q&A at the end. It's up to you how long it runs, maximum an hour, but the more questions we have, the more we will look at or discuss in the webinar. So feel free to enter your questions at any time so that we really have a good collection of questions.

At the right-hand side of your browser, you'll find the question sections or at the bottom if you use the mobile app. We are recording the webinar, and we'll make this webinar and the sliding available short term after the webinar. So what I really want to look at is why is PBAM so super important?

Why do we, should we think about it, and why it's maybe the latest time that we move from discussions and point solutions to widespread adoption? As I've said, there will be a second part, which is the Q&A. So don't forget, entering your questions. And by the way, for the Q&A also, there's an option where you can vote for questions. So you can shift questions up, and I vote and work down from the sort of the favorite questions, the ones with the most votes, down to the ones which have lesser votes. And as I've already said, I'll start with a poll.

And this is, how are you planning to shift to policy-based access control or policy-based access management? So I sometimes use PBAC, sometimes PBAM as terms. I use it quite interchangeably. Do you plan to shift to this as the model for authorization and for options, or you don't have current plans? You plan to do it for selected areas. You're currently in the planning phase, but that's really using it, or it's already widely used. So I'm really curious in where you stand with that.

As usual, we'll leave the poll section open for a while. You'll find the poll on the right-hand side again. So it goes to the Q&A section or at the bottom in the mobile app. And so looking forward to your responses on that. And as I've said, if time allows, then we will look at the results during Q&A.

Otherwise, we will also close to EIC, our European Identity Cloud Conference, which runs June 1st. Close to that, we will also publish around the data, publish a report, a survey about the sort of speak, the state of identity management, digital identity. And then we also will consume some of the poll data for that. So I'd like to start with a bit of a, I have to say, in that case, a faked whiteboard session because I prepared a whiteboard app. So I don't draw in real time here because I don't want to make a big deal out of it.

Because you will observe that my handwriting anyway isn't very good. And if I do it in real time, it becomes worse.

So, but I think it's a good way to share some of the thoughts I have about this subject. Some of the thoughts I have about my perspectives on policy-based access and why I feel this is so important. Before we then go into more sort of some slides where I also will provide some background, some context. So this will be basically the way we look at it where we're gonna run this webinar. We have quite some content. So I'm not sure exactly how long it will run, but I ensure that we have enough time for the Q&A. So when we start with policy-based access, this is something which is not really new.

And policies specifically as a concept are not really new. We have policies in many, many areas in the last just a minute of IT and in the real world as well. Because a policy at the end of the day, what is it? It's a subject, an action, object, and constraint. You can use a bit different terms like for the action, et cetera. But at the end of the day, it's a subject. Martin is either granted or denied. For instance, Martin is granted access. That's the action. That's an object or this file under certain constraints. Or Martin can access this data set.

So access to a data set, but only for the records. If Martin were a salesperson, that fall into which are related to accounts, Martin is managing as a salesperson. That's the constraint there. So the structure is basically always the same.

Someone, which also could be a single service, whatever. An action, an object, constraint. Really our policies are the same.

Child, don't touch, put over. Subject, action, object. So it's not new. Constraints could be complex, can be complex, can be nested potentially. So we can play around with policies, but they can have relationships. But it's all, I think, very, very clear. We use policies very frequently. It's nothing which is in any way new. So as I said, Martin building access policy, only when Martin is able to enter a building, he can sort of speak, then access the computer or a firewall and so on. That's a relationship thing.

So we have policies and the concepts basically, I believe, are familiar to everyone. So policies aren't anything new. And this is one of the charming things with policies. We can express them in natural language. We have a standard structure across many use cases. The firewall policy basically, in its basic structure looks pretty much the same like Martin can log into his computer only at work hours. This packet only, or is only allowed to go through port, whatever, 25 or whatever. So always the same subject, action, object. They are a bit ubiquitous, I think, for this reason.

In many areas, and in IAM we find them, but maybe not enough. And this is my point for today. You shouldn't find more policies. You should use more policies, not entity access management. So we have firewall policies. We have authentication policies. That's an area, by the way, of IAM where we use them very frequently. So when you look at all this risk and context-based authentication stuff, then it's based on policies. So if the location has changed a few seconds ago from Russia to China, be careful. If Martin is using a device that has a device binding, registered one, fine.

If not, ask for other proofs. All this stuff is policies. We have birthright provisioning. We have segregation of duty policies, maybe that's first. Very common, specifically at a business application level, birthright provisioning. In identity management, in ITAD, Identity Governance Administration, we can do a ton of things with birthright provisioning where we use certain attributes.

So if Martin is at the location of Stuttgart or Wiesbaden and whatever, this role in the organization, that sort of hierarchy level, et cetera, in this department, certain types of access entitlements are granted. They can be automatically provisioned based on the rules which are behind the birthright provisioning. I tend to say we should be able to, so I raised the bar a bit high, maybe, but I believe we can do up to 90% of the entitlements average user needs based on automated rules, based on policies, which has a huge advantage. So maybe it's only 80%, but I believe 90% are doable.

And this has a huge advantage. If we assign it via policy, then we know it's assigned automatically. You don't need to check for, do the certification for all the manually assigned entitlements. Remove a lot of burden if you do it right. Policies are super helpful. Building access policies, physical access policies, however you name them. A lot of other policies in cybersecurity we have.

Okay, some of them don't work as good as they should, maybe authorization policies. Yes, we have concepts here.

We have, for instance, XACML. As the X and the M and the L indicate, it's more the heavyweight, a bit outdated type of approach, but it's there. So we have seen it. It's in use in certain areas. We probably need to get a bit leaner here. We need to modernize. I'll talk about this in a minute, but it's not new. And by the way, to be very clear, this entire topic is not new. One of the questions I tend to ask is, so do you know when RACF has been released? It was 1976.

So RACF, the Resource Access Control Facility on IBM mainframes, basically it's a system for a policy-based access control, which is about which resources can you access under certain conditions. So it's not new. It's nothing we invent now. It's just something we needed to make earlier. Zero trust policies at the very core.

Again, something I'll touch. So we have export control policies, ESG policies, as well beyond the stuff we look at today. So it's there. And then we have a bit the old-fashioned way of dealing with policies.

So we have a PDP policy decision point, a PEP policy enforcement point, the applications users going to applications through the PEP, through the PDP, which then accesses PIPs, policy information points, like databases and directory servers, and consumes data we use in the policymaking, because at the end it says, if Martin, for instance, is the account manager of these sales accounts, then we need a system that provides us information about which of these records are assigned to Martin. So we need a policy information point. We have a repository of policies. We manage these policies.

So this is the way we do it. In a bit more readable and nicely looking form, it looks a bit like that. Users access requests for resource, policy enforcement point, request responses to policy decision point, consuming information, being managed repository in there.

Basically, that's the way we do it. And then we have a new way, which comes in more and more, which is OPA, your policy HLM, related to a language, Rego. And this is a widely accepted approach.

Nowadays, also there's a lot of innovation, a lot of add-ons we see here, which is loved by a lot of developers, because developers want to sort of offload the burden of managing this. It's much easier to build a business application, business service by saying, okay, if there's an authorization needed, and I ask the component, I ask the HLM, instead of hard-coding it, which is anyway not a good practice, hard-coding authorizations isn't a good practice. So offloaded to an authorization system.

There's still a lot of room for improvement and other things around it, but the idea behind that basically is good. So it's users, they come in through resources, there are AP requests or service mesh to the APIs. There are queries again to the agent, and then there's a policy store and data store. So policy store has the PRP, data store has the PIP. At the end, it's not so much different. At the end, basically still a PEP, PDP, PRP, PIP, all the things you can find.

Again, in a bit nicer looking drawing, it looks that way. It looks that way. So it's a component that serves the service mesh to APIs with the authorization decisions based on the backend stuff like a policy store, managed policies, all that stuff. In some way, very similar. And this is popular. This is really popular. And we have attached policies at the core of zero trust architecture. So we have zero trust. We have this model of NIST, where again, we have a policy enforcement point, a policy decision point.

We have the control plane, the data plane, where we then move from untrusted areas, where a user is advised, going to a resource, which is a trusted device. And so we have a lot of systems that help in verifying that this is really, for instance, marking as the correct device binding, et cetera, like the IAM systems, like identity verification providers, like endpoint protection, detection, et cetera. And so we also have the systems that help us further in the control.

So this idea, also, again, the NIST zero trust architecture is something which shows the importance of policies, because this is really, when you go to the NIST documents around zero trust, this is a very core of NIST zero trust architecture. So we should look at this. The challenge is we have a lot of approaches here, and I talked about a ton of different types of policies. The challenge is we need to make it work in a manner where we reflect that in some areas, it's easier to do, in some areas, we are more advanced, in some areas, it's still complex, hard to do.

It's not only one person or department who decides about what we do, but you have the developers of digital services. You have your internal IT and the access control. Two very different, frequently very different worlds in your organization. So we need to look at this and think about how can we really make it work? And there are a couple of things.

I think the most important one, when you start thinking about this, thinking in a multi-speed approach, that there's not the one big PBAM, PBAC concept across your entire organization, but it's really more a concept that is about saying, I have a plan. I have an idea where it is setting. Then I work in different speeds at different levels of this moving forward. So make it work. Start with a concept to work, understand the concepts, understand the potentials where we stand, and I'll talk a lot about this also in the next couple of minutes. Look at the standards and how they evolve.

Look at how this impacts software. I personally believe that principles like security by design and privacy by design only can be implemented successfully when we rely on the externalization of authorization from the sort of the code into components we can control with politics.

Otherwise, hard-coded, it's extremely difficult and impossible to say it's really a security by design and privacy by design. It also makes us, it makes things much more configurable. For privacy, it allows us to say, okay, depending on the privacy controls, they go into policy. We decide which data is used in which way or presented in which way. All these things can be done very easily with policies. So they have a huge impact. We need to understand how policy life cycles look. We need to look at policy governance and we need to look at data governance.

And a point I'll touch later on a bit more in detail. But basically the point is, when we look at data governance and policy governance, so it's easy to set up a certification cycle for policies. It's easy to set up life cycle policies, create policies, you approve policies, put them into production, all doable. The governance aspect is an interesting one then.

So yes, we have a policy, it's a life cycle, but the policy consumes data. And we need to assure that the data used, the data for the policy information points, whichever time is correct. So we need data governance. So I'll touch this again a bit later. This leads us to sort of a multi-speed concept here. And with that, I'll leave the whiteboard. And a few of you may have seen a bit of the whiteboard in one or two other presentations I did. So it wasn't entirely new, but I hope it was still relevant and informative. I'd like to, again, hint on the Q&A.

I think we have a few questions here that for whichever reason aren't approved automatically. So feel free to add questions, to vote for questions. The more questions we have, the better it is. Because as I've said, we have really the time and opportunity for discussion, what I'd like to do then later on. So I think when we right now look at this entire thing from a broader perspective, then we know IAM is a big thing. It's a very complex area. This is the picture of the identity fabric we've created a couple of years ago.

And I think it is getting picked up by more and more parties in the market as a model that gives us a sort of a holistic perspective on IAM. And we need to work with this. And I think what is very important there is we also need to enable when we sort of zoom a bit into the upper area, then we have this upper part of capabilities, which include, for instance, for entitlements and policy management, but which specifically to the upper left edge include this digital services and identity API layers.

And this is clearly a very interesting and compelling starting point for all the work around policies. Because, or why, what is behind it? What is the idea behind it? So traditionally in identity management, we frequently or mainly have a sort of, so to speak, an inside-out approach. So from our identity management inside, we go out to applications to manage these applications. We manage settings in these applications. We push things in. So we create the accounts, define entitlements based on groups, et cetera.

Here, we need to turn it a bit around. Nowadays, we need to turn it around. We build applications, digital service. They rely on the identity. They rely on the identity of our customers, consumers, things, et cetera. And not every service should create a known new identity. It doesn't make sense. Not a very good customer experience and a good user experience. So the digital service must consume identity service. So we must expose the services through an identity API layer and a core service therein. It's not only create an account and things like that. It's also the authorization service.

So we need the policy part for the authentication, sure, and for the authorization services of such a modern identity fabric. My perspective is that without a policy management, without a policy-based access control approach, which surely will evolve because not everything is really perfectly readily available. But without that, without such an approach, we don't have really a fully implemented modern identity fabric. It's a key element. And this is what we should look at. This upper layer is a very essential, very important element there.

So again, policy-based access. So what is, what we can do better? And some of these points I touched. As I've said, very ubiquitous use. We really should think about what is the potential? And I think when we look at the potential, some of them are very, very clear. So I talked about adaptive authentication, something we use widely, which makes sense. Fraud detection in financial services at the authentication and the transaction level, very much policy-based. Zero trust, I touched on, I'll come back to that later. Dynamic authorization, I think is the point.

How can we do trust in time, dynamic authorization-based access? Runtime decisions about margin is allowed to do that or not. One of the cool things in that is, when a policy changes, it immediately comes into effect. When we use traditional static entitlements, we need first to provision to the target system, which can cause some major delays. So policies are much more dynamic in their nature when we employ it the right way. This is something I really like with policy-based access, that we can do that better in a different manner. So I think we should look at this from that perspective.

How can we make better decisions at runtime? How can we work with that? And this also allows us, in that sense, a trust in time access.

Sometimes, and that's something we also need to look at very clearly and thoroughly, sometimes it's hard to do when systems still builds like, take a standard file server on entitlement structures that are built and written into the file system. Then we probably need to rely on those, unless such a system supports full policy-based access control, full dynamic authorization, and asks at runtime. But we may be able to use something, I tend to call it dynamic binding, which means I map margin at the beginning of the session to a set of entitlements.

Could be through, and I don't like technical accounts, but in that case, we may use it. So technical accounts for group binding, which are removed by the end of the session. If I then bind, so to speak, as well, authentication with the session management, and this binding to entitlements, then I can do really things that are just in time provision, fully policy-based. I also can imagine, or envision, that we derive static entitlements from policies. A lot of the static entitlements, I think, are in that sense self-explaining.

If you have a good policy, we know which detailed static entitlements on a file server, on a SharePoint server, et cetera, we must create. That's definitely some hard groundwork to do, to build such systems, but it would be doable. You're not yet there, I haven't seen anyone doing that. And then my main point really is, we get better when it comes to roles and have lesser certifications. So policies, and maybe let's step a bit back. So what is it, what really is challenging to us in identity management?

I would say amongst the top three challenges in identity management, there is application onboarding across the different identity management applications. Tricky enough for IGA, but if you look at PAM and EC, this management gets even worse. The second one is role management. I've seen a lot of role projects stalling. It's sometimes really complex and endless discussions. Probably a lot of you have seen that. And then there's the third area, which is recertification.

I don't know a single organization worldwide, but a few would say, hey, certification is what my department managers really are waiting for. It's so much fun for them.

No, it isn't. It's a pain. And part of that is that we probably didn't start at the right point. When we create a role, the role in some way is an implicit translation of a policy.

The role, at least with the entitlements. Say, users in this department, and I group them into a business role. So user in the department or salespeople group them, group them, get these entitlements. This is an assignment of a role to certain entitlements, but it comes from policy. And fortunately, we usually don't write down the policies. If we would write down the policies, we would have much more clarity about the roles we need and about the entitlements we should assign. And this is something.

And the other thing is what we do based on policy basis, much easier for recertification policies on natural language, can be translated to natural language, easy to understand a very clear, better way. So we can overcome really a lot of the challenges given identity management by doing more based on policies.

Again, quickly touching the list zero trust concept. And by the way, still Q&A is open. Enter your questions. We have a few, but not enough right there to say so.

Come on, more questions, more interesting Q&A. List zero trust, published in the SP 800-207, puts policy at the core, I've talked about it. Because policies aren't always verifying. This is we check against the policy, do the verification against the policy. This is what we do. Based on the policy could be probably more precise. To say here. So this is, I think, another very important aspect. This entire thing can be very authorization focused. And at the end, I believe authorization is a bit, again, I swooped in a bit.

Authorization is again a bit the, not missing, but the, a bit, the aspect of identity management where we don't put enough emphasis on. So we started doing a lot of our own administration. We have the access governance and analytics, risk and other things. We made huge progress around those indication. But when it comes to that part of authorization, trust and time access, policy-based access management, and privilege escalation, and privilege access management tools, stuff like that.

Then we definitely, so we do a couple of call screens, this Web Access Management Authentication Federation, all these tools. But we are definitely not good enough. And I think we need to spend really more time. We need to fill that gap of this area. By the way, this picture is built on the, I am reference architecture. We have to find a clinical analyst. So it is something which we need to put more emphasis on.

Clearly, it's easier when we develop the applications. It's more complex when we rely on existing applications, because only when these support these concepts in some way or another, it works well. Otherwise we need sometimes to probably do some bypassing thing, can fix some things, but the more legacy, the harder it is. But it helps us in going to things like trust and time access.

And I remember I had conversations probably eight or 10 years ago already with some, for instance, large banks saying, hey, for our internal world of identity management for IGA, I can't we have trust and time provisioning at least? Provisioning that writes the current entitlements into a system and removes it. I think the dynamic binding idea I quickly touched before a couple of minutes ago, might be the better one, but basically it is something we should think about. How can we go more to trust and time? Because studying entitlements, standing approaches, this causes problems.

It's not the right way to do it. It's hard to cover and it causes so much trouble. We need to get better here. I think this is also a call to action to everyone who creates software. So ideally every software supports some way of dynamic authorization. Keeping in mind that still standards probably are evolving, but I think supporting multiple interfaces isn't a rocket science. So currently we are a bit in a situation where we say, okay, we have, sorry, this initial picture we have, so the user sends a request to an authentication authorization system and the service trusts.

So this is the typical way of this type of access where we say the system, so the application goes, we got a PEP, et cetera, to the authentication authorization system and that makes a decision. In a trust and time provisioning, it would be that as a request, the system provisions the entitlements, the access happens and the entitlements are deprovisioned.

And there also could be, this is something we find more and more in privileged access management solutions, that there are trust and time access credentials so that a certificate, for instance, for an SSH certificate for a privileged session, it's provided just as runtime and there's a very short-lived certificate then to access the service. But what is the challenge behind it? I think maybe the biggest challenge we face in this world is governance.

Still, it looks simple, but it's not as simple. We need a centralized policy governance and this must be really central because there's only, then if you create many policy governance approaches, then we, again, will come into trouble. So it should be from the, whatever OPA stuff in a digital service to trust and time privileged access management to legacy applications everywhere and reusable because a lot of these policies are not for one domain. We also think in the hierarchies that come to this point in a second, where policies are linked at different levels.

That again means we should think in a more holistic policy concept. And from that perspective, policy governance needs to be something which has a more central perspective where we need to bring things together. Going back to what I talked about, this multi-speed concept, this multi-speed approach thing. And so this is a bit, what I believe is very important. We have data, so policy decisions build on data. I talked about it. We need a data governance piece. So can I trust the data?

Is the system, whatever the information about it, which customer records are assigned to which sales account, come from, is this a well-managed system? Can I trust the data? We need this. We have to bifold the aspect of policy governance for policies and for the data as a consequence of that. And as I've mentioned before, we need a very comprehensive policy lifecycle management. So this is a bit of the perspective on the, this, some of the things I have around policy-based access. But maybe let's go back a bit to also the market.

What we recently did is we created a leadership compass on the policy-based access management market. As with every leadership compass, there are a number of vendors in the rating. Others sometimes refrain from the rating or decided to be just on the vendors-to-watch list. But we have quite a number of vendors covered here. We see this market evolving. I look at just the product leadership. We have different perspectives. As many of you may know, innovation leadership, product leadership, market leadership, and the combined or overall leadership. There are other vendors in the market.

We see more vendors entering the market. So the next edition surely will be even a bit longer, a bit more comprehensive than this one. But it's a market where we have options. Most of the vendors cover a certain aspect of that. So they come from different angles. They do different things. But there is technology out there. The leadership compass is available in various forms. Becoming a customer of our research subscription customer, probably the best way to do it. Depending on that, we also have access to the analysts and so on, all that stuff. Have a look at this.

We also have something I'll have it later on, how Casey opens the leg, which I think we'll have PBM on relatively soon, which can provide some buyer's compass information. So which are the key capabilities, critical capabilities for this market, where you can then look at, depending on the capabilities, who would be probably your shortlist candidates, number one, stuff like that. So we have a lot of tools in different forms you can use in that, including the leadership compass. So that was basically what I'd like to share with you. We then quickly move to the Q&A.

And I see that the list of questions has grown massively. Poll number two is up. So the question here is, in which area do you see the biggest potential for PMAC or PMEM? Is it authorization service for digital services? Is it replacing RBAC and IG? Is it policy-based that controls API security? Also one of the areas where we see a lot of limitations, or is it others or none, if you don't find it in the list.

So we, again, leave the poll open for a bit. But in the meantime, I'd like to go directly into the Q&A section. So as I said, we'll do Q&A. You can vote for questions, which is always, I think, very helpful. Given that I'm in a remote place, I have to look at my phone in parallel for reading the question, so I may look a bit more distracted than usual. So the first question I'd like to pick, in the meantime, again, hinting on our European Identity Conference, the absolutely must-attend event in digital identity, identity management, cybersecurity. Don't miss it. A ton of interesting sessions.

I think we will have some 230-plus sessions there, 250-plus speakers. It's a really good place to be in identity management. It's a hybrid event, so virtual and onsite tickets or hybrid tickets available for you there, hopefully.

So, but let's start with this. How do we best navigate the environment where we have variations of RBAC, policy-based access, attribute B access? Should they all be merged into one evaluation model? Or should we stop using one over the other? I think that's an interesting question. We have a couple of different terms here.

Like, as I said, we have the ABAC term, attributes-based access control. We have the RBAC term, role-based access control. We have the PBAC, policy-based access control term. I think we can probably understand PBAC quite a bit as a modern successor to ABAC from a terminology perspective. So this isn't really entirely new. The point is that RBAC to PBAC or ABAC also is sort of a continuum.

Role is, at the end, one attribute. We can consume roles. And we will also have roles. Even if we work with PBAC, we need to think about groups of users, groups of populations or identities. And in that sense, we will have roles as well. So we can work with roles. We can have both for the legacy where the role-based part will not go away quickly. This will be there for long, let's say long, to avoid a term ever. So we probably have both. I think the art is to make a transition more and more towards policy-based approaches, less input and less emphasis on role-based.

Also, probably thinking about how can you get better in role-based access by starting with policies? As I've said, the policy is the starting point. And the good thing is roles are an artifact. Artifact contains artificial. Roles are something artificial. I think this is part of the trouble in many role projects that we think about artificial things and how to set this up. If we have policy-based access, we start with the policy. Policy is something we understand. Everyone can express the policy, can derive the roles. So we can make role management better.

And I think this is also one of the things that we should think about. So it's a long journey, still too long.

Yeah, I think we had a peak 12, 15 years ago, probably 12 years or so when XACML became out. And then it's, again, was quite some dissolution, some practical use, but not as widespread as it should be. OPA pushed the next wave. I think it's a journey. But also when you think about how a lot of other things changed, this is probably going beyond what we can cover here. But when I think about a lot of other things, we can look at them. Take decentralized identities. Decentralized identities gives us a lot of proofs about that Martin has.

We can use policies to decide about what we allow him to do based on what the proofs in his wallets are. Then we need way more policy-based access control.

So for me, it's a journey, it's a convergence thing. That's the way I believe you should look at it. So the next question, and again, you can vote for the questions. Voting has a huge advantage that I can sort of focus on the priority test questions. So the next one is here. I'd be interested to hear your thoughts on how initial policies may be derived in a birthright scenario. I probably would phrase it for birthright scenarios. So how do we come to these initial policies?

Because of the birthright scenario, it is that we say, because Martin is in this department that location has this job title, works in this project, whatever else, we grant him certain access. This is an automation that can be done as I would say, at least in most IGA tools. The question is, how do we come to these policies? And the answer is, we speak with the ones who are responsible for them. The good thing with policies is the business people understand this. It's something which is relatively simple to understand a policy. They can express the policies.

If you ask someone, which business roles do you need in your department? And to which of these IT roles or sets of entitlements they should be assigned, this is complex. But the people can express that members of this project team should have access to this team's room, that the ones who are assigned as the managers of the project have a specific role in the team's room. And then we can derive the rest from it. So we can do things much easier when we think from policies, because this is really this aspect of translation.

Yeah, and then there's this interesting question of from an IGA point of view, you want to know who has which rights and which applications. OPA is more the other way around. So how do you safeguard a single source of truth for entitlements?

And again, that is the point where we talked about so a bit, just policy and data sync. So we basically define policy that says Martin is entitled to do that. And this is then enforced because in an ideal world, the application would ask, say, okay, this is the access, this is the mapping to the policy, and policy is executed, correct data is used, done. So in that sense, we have the ability to do that, we can govern it by the data and the policy. There's one, I think, huge difference.

I think from an audit perspective, static entitlements have some charm, maybe as a sign of causing a lot of work. That's it, that they can charge for, but it's a different story. I think they have one charming aspect. And that is, you can trust can read them.

It says, for that file, this access control, here's data that. In reality, it's a bit more complex. So I started my career in the early land manager network. And when you look at the inheritance concepts, try to understand which are the effective entitlements, then it wasn't that simple to have a single source of truth because it was really difficult to figure out what Martin is really allowed to do, and then to understand. So I think with policies, it's a way that changes. But at the end of the day, it's a good way to enforce them. Why do we do it the interesting way we do it?

Because security reasons, because we compliance reason we want to, you must enforce these privilege principle, need to know principle, all that can be expressed in policies. And if the policy is correct and the data is used the right way, the policy is queried in the right situation and you're on the safe side. It's a different way. I don't think it's more complex, but it's different in the way we manage it, et cetera.

Okay, another point. Reuse of policy information also can be dangerous because we don't know who has access and we are not in control. How do you be sure the policy information is all used for a specific application? And I think we can even expand that question to, if there's a policy that is used for multiple purposes, how do we ensure that the policy is still correct, who owns it, et cetera? That goes back then at the end of the day to data governance. It goes back to policy governance. We need to have a proper governance, we need to have an ownership, but basically it's not new.

You know, when you create a business role that contains multiple IT roles that map to different types of systems and their entitlements in these systems, then you have a system owner, A and a system owner B, but the role combines them. So you need to transfer of ownership to do it right. If you don't do it that way, you're also, your RPEC concept breaks. You need to do it in a way that transfers us, that says, okay, and if the previous owners don't agree with that, then you can't combine it into something. The same is at the end for policies. You need the ownership definition.

You need to know who's the owner of that. You need to have a data owner and data governance about who controls the change, the usage, et cetera. I think you can do it.

But, you know, it's nothing we don't have as a problem nowadays. My favorite example is provisioning or access through the Microsoft Active Directory, the groups they're in. So we have an Active Directory group and we say, in this Active Directory group, we use this Active Directory group for controlling who has access to that application. And the next application says, oh, here's a nice group, fine as we use that. And then it's blurry. So the problem is here. It doesn't, I think at the end, it's an ownership thing. In that case, you can't handle it well by ownership.

We match access via AD group world. More or less impossible to do it well and right.

So, yeah, nice question. I just, again, that I didn't miss any questions.

Martin, do you think there could be a world with one PBX solution for all applications? Or should we have a few PBX solutions for every applicable application?

As usual, the truth is somewhere in the middle. There are things that are very good for application development, digital services. There are ones that will evolve more and more for the legacy world. There's the use of policies and authentication. So we will have a couple of solutions. I think that the art will be to have at least a consistent governance approach. I think the first thing is to ensure that the way of thinking is, and that you bring together different stakeholders to work together, to think together about the challenge, despite the challenge of multi-speed approaches.

And at the end, to limit the number of policy silos. I think the worst thing which can happen is that we have, at some point, a lot of policy-based access management, all siloed. So try to keep the number of silos low, try to keep things consistent, at least from an organizational, from a conceptual process and policy, in terms of guidelines, rules, so the written policies perspective. I think this is something we should look at and try to push on it. So a couple more questions here.

Maybe in the meantime, before we go to the next question, or maybe we can bring up, I think I can, we can bring up the, it's already, I think, displayed first poll results, if I see it right. So the loss of planning, where are you? And I think it's, it's a relatively high number of people saying, we are planning.

And using, I think, there's a point in the nature of webinars for a specific group of people. Broader the group would be the, lower the responses probably would be. But I think we see some trend of adoption to say, we are using it more. It's more widely used, it's more interesting. And I think this is quite interesting. And I think also then, when we look at maybe very quickly, it should display now or soon at your end. When we look at the second poll, which was around, which area do you see the biggest potential for policy-based access controls?

The digital services, so the OPA stuff is very, and OPI and beyond stuff, to be very precise. So that must not only be, or it's not only a OPI, but OPAs, OPAs are very prominent here, very important. Potential in RBAC, very high, IPI security, very high. So we see this as a really mixed response, I dare to say here. We probably will see more adoption, more use cases.

I hope so, because I'm a, as I've said, I think you probably have felt that I'm a big believer into policy-based access control. So let me look for which other questions we can take.

Oh, yes, slide 17, a semantic question between automating static entitlements and automating dynamic entitlements. Yes, I'll think about a slide, nice hint here. So what happens if a user role change? So what happens if a user role change? And how do policies work versus how does the scale?

You know, I think term birthright provisioning, for instance, is a bit limited because it should be something which you also do in every mover and relocation and whatever process. And then it's about figuring out which policies stay in place, which come into play. How do we sort of change the provisioning? Good thing is if we know which entitlements have been assigned to margin due to which policies, we can handle this from my perspective extremely well with technology.

Okay, I think there are two more questions. And I see, oops, my Q&A disappeared quickly. But I think we have two more questions to go that would fit neatly into the time I have.

Okay, a second time, a similar question to what we had. Could we expect one centralized policy enforcement points, technology, et cetera, for all kinds of margin platform? Probably not. I think that the chances are that we had a governance level at the management level, lifecycle management, et cetera, come very close to having one system. But the implementation for different use cases will vary.

Okay, the other one is really more hint on me, not really a question. So I think we're done with our questions, basically. I hinted on EIC, I hinted on the KC Open Select. There's a lot of research and there's permanently fresh research published. So look at also the options to interact with us, to work with us. We also have a great advisory team that also has done work on this from a conceptual perspective.

With that, it's about me to say thank you to you for listening to me and hope to see you in Berlin. It'd be a great pleasure. If you'll be there, try to set up a meeting with me early so that you find time to speak to me personally. Looking forward to that. Thank you.