Policy-Based Access Control – Consistent Across the Enterprise

Hello, my name's Graham Williamson. I'm with KuppingerCole Analysts and I have with me today, Gal Helemski co-founder and the chief innovation product officer from PlainID. Hi Gal. How are you? I'm fine. Thank you. Today's webinar is on policy based access control, and we're going to be talking about generic access control. What do we mean by policy based? And then we're going to go into some specifics of the plane ID product. Okay. In terms of a marketing slide, I get one marketing slide. And I'd like to tell you about the KClive events. If you've not been to a KC live event, do try one.

They are a virtual event whereby we can learn a lot about the, the, the topic in on the discussions on October 20th is a, the customer technology world starts. That's going from October 20th to 22nd. And that's, if you remember the customer identity world events, in-person events is the replacement for that on the 20th as well. We also have a session on the tools choice, addressing specifically privacy and consent, and then in November, the leadership summit. So you can go to one of those events you're encouraged to do so in terms of today's webinar, it's this, there are a couple of points.

Audio control is, is, is, is not possible for this number of attendees to have online audio. So you're all muted, but we do want your questions at the end, but then have a question and answer session. So on your screen, you'll see a section for entering your questions as we go, please put them in there and we will get to as many as possible at the end of the webinar, the webinar is being recorded and will be available by the email. There'll be email leaks.

And to those of you who have registered, and it will be available on the KuppingerCole website in terms of our content, we're going to be talking about some of the importance of, of policy based access control. It is increasing in importance these days, and for any identity and access management management practitioner, we strongly encourage you to have a good look at policy based access control and what it can do for you. Then I will specifically be going into the plane ID solution and seeing how they approach that plan ID takes to constructing a policy based access control.

And as I said, at the end, Ben, we'll be going into questions and answers. This, this slide has come from a market compass document. If you want to see the market compass document, that's on the website and it's called dynamic, both authentication management and policy based access control is a sub is a component of both dynamic authentication management system. There's this three main drivers we see at the moment for a policy-based approach. The first is to come out with consistency across the enterprise. What we're looking at here is, is externalizing the access control decisions.

So in the past, many of our applications have done their own access control. They maintain their own identity store and they determine who can access what's in the enterprise with a policy-based approach. We don't do that. We S we remove the access control logic from the application and rely on an external, authentic authentication service, which will look people on to the functions within the application. The big benefit of that is we can now have a common approach to access control no longer do you have to go see managing finance to get access to the finance application.

It's all managed consistently across the enterprise. It also allows us to accommodate diverse requirements within an organization. And that's one of the main drivers now pull the adoption of policy based approach because it allows us to accommodate what's ever happening in our cloud migration program. How are we coming together, integrating on premise with cloud infrastructure, how we're managing multiple cloud service providers. Those can all be accommodated with within a policy-based system. And of course it allows those decisions to be made in real time.

So rather than having an entitlement set up at some time in the past, we now evaluate the, an access control request in real time. So that means if somebody, for instance, changes department, they moved from one department to another department during a day from the moment they're shown to be in the new department. The way that access control requests are going to be processed will be different. It'll be based on the new information gal. How important is that to base our policy and access control decisions on real time data?

Yeah, I think you will see an increasing need for such solutions because you can no longer rely on predefined static definitions to keep up with the dynamic requirements of the current, eh, eh, application landscape. You need to be aligned with your security initiatives, with your layer of risk control. And the only way to do that is to be also dynamic and more advanced in the, in your access decisions. Right. Okay. It is now the way many enterprises are moving in order to accommodate real time changes in, in, in, in, in data.

So, yeah, as you mentioned as an important part of the cyber security approach, this slide, I wanted to just show this slide. The, this is from the market compass document. And what is clearly showing is that policy based access control is a mature approach.

It's not, w we're not on the, the frontier here is a mature established technology, but the clinical sees is importance increasing dramatically over the next few years, simply because of the market drivers that I've just discussed. We need to understand that policy based access control gets us the benefits that we're looking for now in our agile decision based systems that we need to work with in terms of the market direction. I just wanted to highlight three in this webinar. The first is the move into cloud services.

Cloud services is now the defacto standard for many it organizations, things that done in the cloud. And we're seeing many companies these days have a cloud first policy. So the legacy applications, the on premise applications are diminishing and agile environment with multiple software as a service applications is increasing. But what that means then is that we need to treat our access control more intelligently, and we need to be able to embed the components of the access control system, which we'll come to in a minute. We need to be able to embed those in our access control logic system.

And the policy-based approach allows us to do that as most important. When we think of containerized software, if we most organizations are in the cloud, they're using containers, it gives some of the scalability that cloud environments offer. And so we need to make sure that each container has a common approach in terms of access control and began. A policy-based system really helps in that space in terms of multi-factor authentication as it, our smartphones are ubiquitous, they are everywhere. And that makes a lot of sense.

If your users have such an intelligent device in their pockets, you might as well use them. So when a policy-based system sees that a particular application to which access has been requested requires an elevated authentication, the policy based system can then initiate that. And it might be to send a request to paid input. It might be requests or an authenticator on app on the device to be, to be used. But that multifactor authentication, which is significantly improving the assurance we have, that the user is in B.

They say they are that multifactor operation is much easier to accommodate within a policy based access controls system. The third one on dimension is the, the way our identity environment should accommodate the various things that we need to do within an organization. And I've highlighted one network monitoring.

Now, policy based access control, doesn't give you network monitoring, but what it does, it's assists in the network monitoring requirement. So, and within KuppingerCole, we increasingly referred to the identity fabric within an organization.

And that, but that's basically saying is there's multiple requirements within an enterprise that need access to intelligence based on identity and a policy based access control system can provide you that. I mean, it can of course do a, a one-to-one relationship. So if I'm accessing an application, the policy-based system can say, yup, evaluate the policy and give me access to that application equally.

The, it can also say, well, who, who can access an application? So if we want to do some analysis on what sort of access people have within an organization, then the, the policy-based access system can do that. So it gives us a much richer environment to manage our access control. Did you have any comment on that, on that gal, in terms of the tools that a policy based system provides? Yes. Sure. So basically I want to emphasize what you say. There are multiple market directions, eh, that today we see requires small tail, more dynamic type of decisions.

And that is well policy based access control or paper. Cause we like to say that's where it comes into play. It enables you to manage those decisions. It enables you to manage those decisions in a central way, but it provides that layer of dynamic and flexibility, which is required to support all of those different initiatives. When do you need multifactor authentication? What is the level of access to cloud services?

All of that can be defined by the policies rather easily to provide the level of foxes eventually you need and provide the organization, the level of control, which it typically requires. And eh, another thing I want to mention you, the policy based solutions supports those initiatives. It's part of the overall I am landscape, as we will also see in the following slides and it can, it can make those initiatives from just a single, a single path to a part of a whole solution. Thank you. Yes. Okay.

One more point on this slide, it's important to make sure that a Butler in any, in any identity and access management environment, that we take an defined approach to how we are going to deploy our environment. We all, we must define it. So there's a definition point up front where we're going to be looking at the access policies and what are required. There's going to be then the deployment of the solution and importantly, the enforcement of that, or the governance that placed over that in environment. And we must not forget that part. Okay.

So again, a policy-based approach gives us that governance capability that we do need within an enterprise when we're talking about a dynamical authorization management environment, which payback is a subset, there are some, so some approaches that are we it's important that we realize is the differentiation. When we come to a dynamic environment, the, the first is that the access points, access decisions, I mean are made by an external device. We're externalizing those access decisions to an authorization service. The benefit of that, what was several benefits that we've mentioned already?

The big benefit is we remove that access control logic from individual applications. Because as soon as we have it embedded in a specific application, then we responsible for the, the, the whole access control is now taken out of the hands of a central policy environment and put into a specific single spot single area. We want to avoid that because we want the consistency of access control across the organization. As we mentioned, the decisions are made at run time. So that gives us the agility that we require and that access could be to an application.

It could be to a single transaction with an application. It could be to a database. It could be to a document store. So that decision is being made at run time. If we wanted to remove access for someone, all we need to do is change the, an attribute of that person, and that would potentially remove their access from that document or application it's. It also gives us, this is a dynamic system, gives us the ability to leverage multiple identity stores.

So rather than in the past where everything was in a central, a central directory service, and we had to then populate that directory service with all the information that was necessary, a policy-based system, it can typically access multiple information points. So part of the information will be in a, B some information will be in a corporate database, some information that might actually be in a database attached to an application.

You know, the, the policy-based device will, will allow us to co to, to connect multiple identity stores, which will give us so much more rich background from which to call. As we mentioned, changes in policies are automatic, automatically made effective in, in runtime. And we can also support multiple ways of integrating with application. So a policy based system, because it's supporting multiple applications, it needs to have interfaces into those different applications and identity stores.

And so they're typically provided within a policy-based system in terms of the components of, of policy based system. We'll just go through them quickly. The main one is the decision point, the policy decision point, it is the component that is actually making a decision. So when the user comes in and requests access to a particular computer program, the decision point will evaluate the identity attributes and context attributes and say, yes, we can do that.

Or no, that person is not allowed to access that, that particular resource it'll do that based on the policy information points, which as we mentioned, could be multiple, will usually be multiple in environments today. Now the connection between the decision point and the applications is an enforcement point. So the policy enforcement point deployments must fit the requirement. In some cases, the policy enforcement point will be co-resident with the application or a component of the application. So the application will make a call through its pep to the PDP.

In other cases, the application will be remote and we'll issue a call to a path which then gets the decision from, from the decision point at the top. There you'll see the pap a very important component because that's the administration one, that's how we actually establish the policies within the EDP. So policy sets will be, will be established through the path and that path to will often be quite complex. It might need to be to, there might need to be multiple pap instances in different business units in order to put together and aye, aye, aye, enterprise wide policy set for the organization.

Now, in terms of the, the process that we should be, we should be following. It's important to realize that the needs to be a process to define our access policies. It's not something that we leave up to various people to do in different ways. So a policy is going to have four main components. The first is the subject, the subject w w is the user who's requesting access to a protected resource. Then there's the action. What does that user want to do? Is it a read only access?

Is it some specific function within an application that's required so that there's, the action needs to be defined, but then there's the resource itself? What is being accessed? This is an application, a computer program. Is it a document in the document store? So exactly what is it that we, that we are accessing? And the last I have about the four components is the context. And the context encompasses a variety variables, such as time of day, the geographic location.

We, you know, whatever we need to segment access control decisions on should be con provided through the context, the context variable. Now gal, did you have any comments on, on context and the various options that we might need to support?

Eh, so not a comment. First of all, this does describe, of course, the, the path into defining a policy. Typically you want your policy to be able to support the relationship between the subject and the resource to make decisions much simpler, eh, to avoid large number of policies.

So that's, that's one part which is important. So just want to mention what we are seeing here are the basics of the, the basic elements of the policy. And once you are going to look into a solution, you need to see the actual capabilities. Each of those areas they actually provide.

Okay, moving into some specifics then of the playing ID solution. This, again, as slide is coming from the market compass document and is showing how, how the, the various components of a policy based access control system are accommodated by, by, by vendors. In this case, you can see that plane ID has a very strong policy administration school, and we're actually going to be coming to that in a minute. And could you screenshot, it's very strong on governance, like is able to give us to support any governance requirement we have in terms of access control.

It's not just can this user access this resource it's ha can this who can access this resource. So it can go through the policies and tell you who can access the specific resource. So that's an amazing, that's a significant benefit for an auditor or, or a governance governance tool in deployment. The PlainID solution has multiple deployment options, which will suit most of my whole corporate application deployments and usability.

So usability is very high amounts and usability because the focus from plane ID is on the support from support for business, people that need to manage construct and manage policies, the graphic user interface for policy writing. I have a screenshot on that in a moment.

It means that we don't need to rely on technical, a technical resource, an it person to write the policy for us w can be done by a business person, but it also, the solution does provide standard interfaces, for instance, supporting the exact model solution in terms of the, the allowing administrators to test policies, that that tool is provided within the system. And it gives us the ability to provide a strong support for, or business personnel. But I'll just move to this next slide and show you a, this is a screenshot of the policy development tool.

And as you can see, is it is indeed a graphic graphically based, and it follows the plainid's who, when, what approach on the left-hand side, the pink dots are the users. In this instance, we're talking a medical application. So dentists are supported and family doctors are supported and they're accessing that green dot the green circle. There it is medical data.

So it's, people's general medical data that is being accessed. You'll see, on the dentist line, there's a red circle. That's the context variable for the family. Doctor's white. And that's showing how this constraints on the dentists access to the medical data. It could be kind of day. So maybe they're just allowed to visit to, to look at the data in a daytime or production time, not at evening, but the family doctor is, has no such constraints. And then the records that are being actually accessed as shown in blue.

And as you set up all of this, you can then click on these icons to get the detail you need to set up the policy. So it's very graphic in terms of showing you how it works and a business person can take a look at that and understand the policy. So it gives us the ability to remove policy development and, and management from a technical person to the users, gal. How important is it for a user?

Sorry, a business user. When I say use it, I'm talking about the, in this context personnel within a business unit, how important is it to give them the access to the policy development rather than a reliance on a central it group? I think it's very important because eventually the policy decision is a business decision. It's not just an it or development decision, the requirements to who can do what within the application, they can form the business team of the application, the application owners possibly, eh, the BAS of the application.

And they should be able not just to, you know, send an email or send a wall document containing the requirements. They should also be able to see the requirements as they are defined and even define those requirements by themselves.

Now, having such a tool, well, the language is graphical. So like you can't see a drag and drop type of solution and neighbors, also the business side of the application to be involved in managing and defining the decisions, which they care about, which they want to see implemented in the application. Okay. In addition, I think from compliance control perspective, that enables you actually to visualize, to see, eh, who has access to what it's not all in code, you can, eh, because you're externalizing the decisions and put decisions are presented in this graphical view.

Now you have better visibility in addition to control over what users have access to which data to which services that's no longer behind the scenes in the it landscape, but you can have that available also for the business team of the application. Certainly thank you. Let's delve a little bit deeper.

Now, the process modeling, because this now gets to the core or the power of a payback system, in my opinion. So at the bottom there, you can see we've got applications. So there's application a, B and C, and those are the resources that users need to get access to.

Then we, the administration level, we say that those applications are actually, and, or manage by two different lines of business. So we've got business unit. One is looking after a and B and business unit two is, is looking off to see.

And, and so we've got now the control of those policies for developing them, managing them at the business level, but the next level up, we, we actually now pull together the policy sets so that we can have some measure of compliance over them. And this is how we come up with our conformity across the organization. Now it might be an auditor that does this as it's shown in this slide, or it might be another staff function within the enterprise that looks after that compliance. But it's important to realize there will be that oversight, obviously various groups will contribute to that.

HR will be part of most environments because they are the keepers of most of the identity attributes. And at the very top, now we have, we have this global approach and there'll be various groups that will be the, this might well be now a CIO type of, of, of control whereby the settings are being managed across the whole organization. Yeah. In your experience, who would typically take that global responsibility? Would it be a CIO type of environment or would it be more in a financial management environment?

Is there any, can you give us any guidance as to who would typically be set up to do that overarching global oversight of policies within an enterprise? Sure. So absolutely it can be, as you mentioned on the CIO level, it really depends on the type of organization and well, the policy based solution is implemented. I think what is important to mention here is the delegation capability, which is provided by the people management system, because eventually we are dealing with loud numbers, huge numbers in some cases.

And the advantage, which is gained here is the ability to delegate responsibility between different lines of businesses, between different areas within the organization, but still get these overall oversight of the whole definitions, which are managed within. And, and that goes to the way which you manage your authorization decisions. Is that going to continue be so complex? Or how can you simplify that?

And one of the methods to simplify is to, to create a smaller management units like you see here and delegate responsibility to the relevant owners with still having this overall oversight over the whole process. Hmm. Very good. Yep. Okay. Last slide. Before we go to our Q and a, the, as I mentioned upfront plane ID solution has a significant benefit in terms of the competitive advantage. I should say when, when we come to deployment patterns, which of course it is a, a major benefit of moving to a payback system.

Gail, did you want to talk about these three areas? Yes. Thank you. So up until now, we focus primarily on how you manage policies and where you gain the benefits there.

We, so policies can be managed in a logical manner and you can delegate responsibilities. Of course you have the full life cycle, visibility and investigation. And eventually when you have all of that capabilities within your management solution, then the other question is, okay, so how those policies decisions are delivered to the application, how do you enforce what we're currently seeing are three main deployment patterns on the right most side, you can see the connection directly to the application providing contextual and fondling the access to the application.

So let's say you have a, some kind of business portal in marketplace. Well, you want to dynamically influence which application objects available to the user who's accessing. That's easily accomplished by just connecting your portal, your marketplace, to the policy manager and gaining that level of control. So this is one pattern. The second pattern, the one in the middle is providing same level of control and eh, eh, dynamic decisions, but through an access management solution, any access management solution is possible to be used here.

The advantage of this type of pattern is that the application would get a single unified interface, for example, open ID connect or summit or whatever you choose to do, but the authorization content of the token would be created dynamically at run time by your policy managerial solution. So this would be the second pattern and the last pattern. That's a very interesting one.

I believe, eh, eh, some of you would, would under, it would resonate with this example because recently we are hearing a lot of requests just around this specific pattern. And that is how do you support authorizations for micro services? Because in microservices you want microservice to be lean, to be focused on the functionality. Your microservice developers should not be handling the business logic of who can access where and what, and you want to externalize that.

So externalizing decisions is very native to micro services, but then the question comes to, we need to answer is, well, where are we externalizing without affecting performance and without affecting security? And the answer is in the form of a sidecar, for example, a small container attached to your main container, which handles or authorizations decisions.

Again, this is only high high-level description of the main deployment pattern. We'll be very happy to deep dive with anyone who's interested, eh, but what we are showing here is the auction options, the flexibility, which the solution can provide, not only in management, but also in enforcing the access and providing that to the application. Very good.

And so as you see there on the left-hand side with the pet being, co-resident in what you're calling a pod, I like that I like that terminology and that is making sure that each, each application container is getting the same decisions from the policy management environment. How is that? Are they typically co-resident like, so for instance, for an organization that might have multiple cloud service providers, how would you actually manage that? Would you distribute the policy decision point to each of those CSPs and then the pets for the pods would access it in, in those environments?

So certainly in a, in a multicloud environment, not only multicloud, but any distributed environment, your authorization system should support the same level of eh, or the same, eh, path of distribution. And the policy system can be a implemented in a distributed model.

Well, you're having different decision engines. Each might have its own policies, and those would answer to different applications. Maybe if you have a very intensive application, you want to dedicate a specific decision engine just for that application. And then other applications might have their own, a decision engine, which they share.

So the, the system is flexible enough to support those multiple deployment patterns. Remember that they all eventually a they're all managed by the same centralized administration point. So you gain the benefits of a mess of a centralized management system with the distributed capability to enforce access, distribute capability for your decision system. Very good. Thanks for that gal. Okay. We now have to move to participants, probably think the most important section, which is the Q and a, so make sure you do enter in the question area, your, your question. So I'm just having a look here.

What we have. We have some interesting questions here. Okay. In terms of, I've got one here on entitlements, and I need to clarify maybe that what I mentioned earlier in terms of entitlement.

So I, I was going back to a classic access control system, which is very, very, usually a very often, I should say a role-based access control system. So what we see is that a, a person joins an organization. And at that point in time, their entitlements are set up and that might be through like a standard access control access re permissions that everybody enjoys often called a birthright. And then people might be put into various groups like managing people through an 80 group. These are entitlements that are established, but they're static. They're not dynamic. There's nothing.

They will change obviously from time to time. But in terms of the access control decision is being based on that static information in a policy-based system, we, we still have entitlements, so it should, but those entitlements are dynamic. This agile led changing depending upon the attributes of the, the user. At any point in time, we can still use a groups in a policy decision. So honestly based system can still access that group group membership information. And that becomes an attribute within a policy, but we, it gives us a much finer ability to control decisions.

I hope that makes sense is another one here is, is plainID in the form of assess application. What, what's the scale, the biggest deployment. Okay.

You know, it's not a SAS application per se Galileo much better to, to answer this question. What, what the what's the, in terms of a deployment kind of policy based access control system, a scale to an enterprise level?

Yes, absolutely. So first of all, plainID is both an on-premise implementation and assess. We have both offerings, eh, available in some forms and it absolutely can scale to an enterprise level.

Actually, most of our customers form the large enterprises in the us, eh, they are part of the overall identity and access management, architectural controlling those decisions to the different applications. Am I serving several, eh, in, in the enterprise, in the, a workforce, several hundred thousands of users and in the external facing several millions. Okay. So it really depends where you're implementing that, but the solution is built for large num build the solution is built to support loud, loud scale in high-performance environment. Thank you. Okay.

Now, in terms of the business unit, w the question question is how'd you get business units to cooperate in establishing policies. What's been your experience of getting a, an enterprise to really accept the responsibility at the business unit level for policy creation and management. Okay. So I think, eh, sometimes it's, it's a natural, eh, process.

Why, because if a business unit, for example, fails an audit report, because it had no visibility, then what it requires is that level of visibility. So they want to be involved. And once they are involved, now they can say, oh, it's easy. We can do that by all cells. So this is typically the process. The tool enables you to have them in, to have the business unit evolve, to be a, a, to be provided to the developers. So you can choose what's the level of deployment you want to do. But I think once you are enabling your business units, just to see the advantage of look, those are the policies.

And in addition to the policies, you can see the actual users, which are out of the policies. You can see the applications and the resources provided that by that application, then they want to be in the process. They want to be part of that. And as you mentioned, an audit is a good incentive to do, to get involved. Okay. How do you make sure that policies established why by one business unit are consistent with other business units?

Okay, so, so, so that's also a good question that comes to the capabilities provided by the solution itself. Eventually, eh, all policies consumed by an application attached to the application, and you can investigate and analyze the full set of policies from the application perspective, in order to see that that is what eventually you have a defined in general, just general answer plan, ID walks as a white listing type of solution, which means to begin with nobody has any access, but then you are starting to define your business logic.

That's the access that should have the red team should access to that project. The blue team should access blue projects. And so on. Those would be again, very simple, the examples, those would be your policies. And of course you can add on top of them, your compliance policies, once connected to the application, the application would act upon those policies.

Again, we'd be happy to demonstrate any of that if to anyone who's interested. Very good. Okay. All right. Can you expand on container based deployment? Yes.

Eh, so container based deployment, eh, this question I can answer in two ways, but let's say, take one path, eh, the, the solution itself can be deployed. Eh, the PDP, for example, can be deployed in container. So you can have your PDP in a container type of deployment. And it means it supports those auto-scaling capabilities within the container framework, enabling you to always provide the level of is their service level you want to provide to your application. So I will solution specifically supports a container based deployment for the solution. Those can be distributed.

You can have as many as you want, and it answers all the standards of container, a container based deployment, Let's say. Yeah. So basically that versatility is a competitive advantage for . I believe it is. Yes. How does payback support data, access enforcement? What tools? I think the question is, Okay, so, eh, data access enforcement, eh, let's talk a bit about that. There are multiple ways to enforce access to data. And the question is, first of all, how are you accessing your data?

Are you accessing your data through JDBC connections, all through API APIs, the answer which we have today, if you're using JDBC connections, then we have built in support for data virtualization solutions. We have some partnership on that area, which we enable a to enforce fine-grained access to data, using data virtualization. That means how and column level access you can actually control very specifically, who can see what the enforcement layer in that case would be all data virtualization.

A layer of that is when you're using JDBC type of connection for 80, for API access to data, such as Google, big query or some others, then the enforcement is done on the API level itself. We also have solutions there. They also play in ID unique solutions.

Again, we'll be happy to expand and demonstrate if there is an interest. Very good. So being able to you, so in a particular database, you can go down to the, even the row and, and in terms of, of access, allowing users access to, to a database, you can, you can tighten it down to that, to that level and attributes within a row like certain columns. Absolutely. So let's say, let's take an example. Let's say you have an account database and account repository. Your policy can state that all of the users can have access to accounts within the region.

And if you are a financial officer, you can have access also to the finance accounts. So someone form, let's say someone from California would be able to access all the California accounts, but he will be able to see only the general data of those accounts.

Like, let's say, first name, last name, maybe address, whatever is defined as general data. If an a financial officer from California would access, he would also be able to see, in addition to the general data, the financial data, let's say the balance of the user and maybe some other financial related information. If someone is accessing now from the UK, they will be able to see the similar type of data, but only for UK based accounts.

So that's how the policy, again, you can see very few policies would answer many, many different scenarios, and this is the level of granularity, which the product provides. Hmm. Okay. Could you talk a little bit about projects that you've been involved in and the specific learnings of those policies that those jokes?

Yes, absolutely. So, eh, we have been involved in, in multiple projects, obviously in some of them, we are a, we are, they're not in a Greenfield type of situation, but throttling an existing situation where authorizations have already defined in some repository or another. And the requirement is, okay, let's take, we are modernizing our application. We are rebuilding. We want to control access through using policies. We want to externalize the policies, eh, but we have all this authorization data. So what are the steps there?

So typically an implementation project is based on two parallel paths. The first one is the technical path.

Well, you implement the badass install, the product, all the connections, which you mentioned the pap. So connecting to the active directory, connecting to relevant, to the positive, always whatever is needed by the specific, eh, eh, by the specific implementation and, and of course, discussion with the developers if needed depending on the project. So that would be the technical path. And then there is what we call the business analyst path.

The business analyst path is to understand the authorization logic of the application and to assist in digesting the current of authorization data and converting that into policies for that. We have a tool that helps us to take existing authorization data and transform it into well defined policies, again, providing visibility and reducing eventually the Nam bills, which have been managed.

So, so that would be a typical project, that project, again, depending on the size of the application, but form development, all the way to production can take several weeks. Doesn't have to take much longer than that. Okay. Would you say that policy based access control then is a major component of an enterprises, identity, governance, environment, identity access management environment, like where do you see payback fitting? Yes. So absolutely. I do think the policy based component is part of that overall, eh, identity and access management, eh, infrastructure.

It works very well with your access management solution. It works fairly well with your AE IGA solution. And it's part of that. If you want to move forward, if you want to modernize your application, your technology landscape, you need a PBX solution as part of that, because PEBA enables you to move faster, to support new technologies, to easy, to easily support new business initiatives. That's the only way you can actually achieve that. And that's why it's an important part of your infrastructure. You you're, you don't need to replace anything.

You're not going to, it's not like the old project of let's replace, eh, old IGA with new IGA. That's not what we are saying. We are saying that you can build on top of what you have. You can leverage what you have, but still provide the best support for all the new initiatives and the new technologies, which you want.

Eh, you want to implement Very good. Well, that brings us to the end of this, this webinar. I would like to thank you very much for your support and for those words of wisdom that you have provided us in terms of the benefits. So policy based access control. Thank you. Thank you. Thank you very much. Happy to be here today.