Fine-Grained Policy-Based Access Control: Why & How?

Hello, I'm John Tolbert, leading lead Analyst here at Cole. And today we're having a webinar about fine grain policy based access control. And joining me is SK the co-founder and C P O from plain ID.
So before we begin a little bit about us Cooper, your coal is founded in 2004. We're an independent Analyst firm with offices all around the globe. We provide vendor neutral guidance and thought leadership to our clients around the world, and we support different kinds of organizations, everything from end user organizations, across lots of different industries to system integrators and software vendors. And we're really focused on a few key areas that would be information and cybersecurity, all topics around IAM and identity governance, GRC, and really anything and everything about the digital transformation. We have three major business areas. The first is research. We do research on all the major IM and security topics. We're vendor neutral, so that we can provide objective advice. We always stay up to date. We do provide other events like conferences and webinars here. And again, to give you coverage of all the leading topics that are in the field today, the events are really good networking opportunities and an opportunity for you to come and meet experts in the field. And then lastly, we do advisory, which are, I think of them as short term consulting engagements. On the end user side, we help organizations do things like do readiness assessments for technology areas and RFP shortlist. On the vendor side, we help vendors validate and come up with product roadmaps. And this way we can help provide the best advice in the era of digital transformation.
So our upcoming events week after next, we have our second consumer identity world event in Amsterdam. That's October 29th through the 31st. And then after that, we will have our cybersecurity leadership summit in Berlin, starting on November 12th and running at the same time is the cyber access summit also in Berlin in November. So I hope you can join us for one of those events about the webinar itself. Everybody's muted. You don't have to mute or unmute. We'll take care of that. We're also recording the webinar and the recording should be available by tomorrow. And then we will save some time at the end for questions and answers. And you'll notice if, or if you notice the go to webinar control panel, there's a blank there where you can type in your questions anytime during this webinar.
So I'll start out talking about some of the high level water, technical overview, and a little bit about the business side, and then I'll turn it over to gal to go into more detail on the business side, and then we'll save that time for Q and a at the end. So I thought I'd start out with just a quick question about what is authorization, you know, authorization, I think has too often been conflated with authentication, even by many of us in the identity field. We sometimes say authentication when we really mean authorization. So I thought, you know, let's start with a definition and by authorization, I mean a runtime evaluation of attributes against predefined, static rules or policies really it's about access control. And then those attributes can include things like things about the user, the device they're coming from, or trying to get to applications, resources that they're trying to get to.
And then some external context information about the request itself, and that could be time location or other Intel about the context. And this is sort of different from authentication, which I'm going with a missed definition here of the process of verifying the identity of a user process or device often as a prerequisite for access control. So almost always we'll, we'll do authentication before authorization. And what I like about the N definition here is it it's beyond user. It also includes processes, applications, and devices. So again, you know, we, some of the terms that we have come up with around authentication or combined with authentication in some cases are about authorization too. You know, you've got step up authentication, you know, in a financial case where you might have to step up to do a higher transaction limit, you're really authorizing the transaction. So we'll dive into that in a little bit more detail later, attribute lookups can be part of that, and that's really not necessarily authentication. And then same thing with risk adaptive, we do risk adaptive authentication, but there's also risk adaptive authorization as well.
So where does authorization fit? Well overall identity? I think there are several major processes or categories of things that happen when building digital identities will start with the vetting. If you're an enterprise and you're hiring an employee, you'll do a review of, you know, government issued ID when you hire. And then there's the provisioning of digital identities that hopefully governance too, so that, you know, entitlements can be added or revoked as needed. And then if you leave the company, your accounts should go away. And then there's the everyday authentication and authorization operations that happen independently of some of those compiled time activities we'll call 'em like the vetting and the provisioning.
Where does authorization fit into consumer identity? Well, it's a little bit different since consumers don't show up, normally with government issued documents and get all of their attributes provisioned at the beginning, there's, self-registration people give information about themselves in a progressive profiling sort of way. And then consent management for privacy is a, can be a bigger driver than access control in some cases, but they still have to authenticate and they still have to be authorized to either look at certain information or perform certain transactions. But the mechanisms for authentication and authorization are sometimes different between enterprise identity and consumer identity.
So this probably looks familiar, you know, back in the early days of computing, we, we created accounts for users, and then we soon learned that it would be easier to group people together, you know, to assign permissions or entitlements. Those persist to this day groups and users can be added to access control lists, which, you know, those still exist today as well. And then there's the notion of roles that developed probably more than 30 years ago, where, you know, you might wanna assign the same kinds of entitlements to engineers, regardless of where they worked or what, you know, what project they're on or a finance person. So it's important to be able to group people together by roles, but then, you know, 15 plus years ago, we realized that a role is just an attribute and there are other attributes you might wanna consider for access control decisions. Let's say if it's a defense or an export control kind of issue, you might need to know a subject's nationality. So that's, that's another kind of attribute. And then lastly, you can use attributes to make policies, to govern access to different kinds of resources.
And this might familiar as well. This is sort of a, an interpretation of the executable, reference architecture, the attribute based access control standard by Oasis for extensible access control market language, you know, and this kind of applies regardless of what protocol or standard you're using in terms of how to think about authorization and access control. You know, you can start with the user trying to get access to some sort of application that access can be mediated by a policy enforcement point, which doesn't necessarily make the decision itself. It goes out and asks a policy decision point, which is most likely been preconfigured by an administrator somewhere at a policy administration point. And those policies are stored at a policy information point, which may also contain the attributes about the user. So you can write policies that say, you know, you need this set of attributes and attribute values to be able to get access to this application and do this check at runtime, which is sort of a differentiator between something like let's say, and Sam, where you can do more dynamic look at run time.
So let's look a couple of different kinds of policies. Let's think on the financial side, you know, you might want to evaluate three major categories of attributes, you know, attributes about the user attributes about the resource, and then, you know, what are the actions? And then there's also the notion of environmental or context information that may include those things like time of day location or external threat or fraud intelligence. But for this one, you know, we'll wanna know the user ID and then, you know, what's their home location. Can you get what their current location is? And then compare that to the home location, then authentication method. How did they log in? Does it meet your policy? Have you said that, you know, in order to be able to transfer, let's say over $10,000 or 10,000 euros, you need to have a higher assurance authentication method is a prerequisite on the resource side, which accounts are the users allowed to manipulate?
And then do you have any transaction amount thresholds for requiring higher assurance authentication in the action? And this example could just be transferring money between accounts. Maybe you have to pay a bill. So that would be the action. In this case years ago for the exact technical committee, we put together a couple of profiles, which are like standard groupings of attributes and attribute values. And I thought this might be a good example, too, for export control. So there are certain items that the governments may decide should or should not be shared with other people or other organizations. And here we have, you know, a longer list of attributes for user and resource that you don't necessarily see in other kinds of use cases. So here we have subject ID again, user what organization or company are they with? What's their nationality? What location are they supposed to be in?
And is there some sort of in agreement ID maybe issued by a government agency for the company to be able to share that information, then there's on the resource side, the jurisdiction, what government agency is ultimately responsible for this what's the classification or the export control classification. Does the organization have the authority to export? This might be a reference to some sort of an agreement ID that you see there on the user side, what work effort is it a part of and then effective in expiration dates and on the action side, it can be typical cred, types of actions plus sending or sharing the information between different organizations. So these are examples of attributes and values that you might want to consider when building this kind of a policy and then even more complex can be intellectual property. And, and again, we'll look at the same three major categories of user.
So the subject ID of the user, what organization or company are they with? What's the business context? Are they a partner supplier customer? What's the subject to organization relationship? Is it the user, a employee or a contractor? And just like with export, there's often a need to have a specific agreement ID that allows the intellectual property sharing to take place. Then there's a classification on the resource side, you know, copyright patent, trademark or proprietary proprietary is usually the word when you're discussing a trade secret. And those are the things that are most need the most protection, but also are really needed in a collaboration space. There's the IP owner who actually owns it. The IP licensee who's licensed to again, is there agreement ID that pertains to this particular resource? And if so, what are the authorized end uses for the, this material and agreements have effective expiration dates as well. And again, there's the same basic a actions credit actions or, or, or sharing information.
So I think there are four major challenges around access control and fine greened authorization here. We've got attribute quality and I'm calling the next one the last mile, or how do you integrate with legacy or line of business applications, policy authoring, and then scalability. We'll try to dive into each one of these just a little bit more here. So on the attribute quality sign, how old is the attribute? You know, they need to be fresh, especially in cases where you have things like effective and expiration dates. And then there's the, what I call the attribute normalization problem. We have a classic example is in, in some domains, the thing on top might be referred to as fire truck. The one on the bottom might be referred to as fire engine. How do you ride policy that equates those two so that you can do inter organizational policy sharing?
And then what's your attribute management process? How are you verifying and following up over the long term, you know, some attributes change some don't, but for the ones that do change on a regular basis, making sure that the attributes are accurate is a necessity for doing fine grained, access control, and the last mile problem. You know, it's great to have a good policy evaluation infrastructure, but plugging it into your existing line of business app might be difficult. Some policy-based access control solutions do come with plugins for popular line of business apps to make it a little bit easier to externalize the authorization, but in some cases it requires redesigning those legacy applications. And of course that means some custom coding to build, you know, some sort of mechanism to be able to ask authorization decision requests of, you know, external systems in many cases, the go forward plan can be well, we'll have to keep using the existing legacy app as is.
And when we move to a new architecture, then we will make sure that we plug in externalized authorization capabilities, then policy authoring that can be difficult. Exactly can be a difficult language to master. There are a couple of different approaches for, excuse me, creating policies. One would be to use natural language tools to allow business people, to sort of write tools in, in a natural language, which then can be translated into something that's machine readable in machine executable, thereby abstracting the details of the policy language itself from people that just need to get business done. Another newer approach would be to use, let's say machine learning analysis techniques to examine groupings of entitlements or permissions matching those up with types of users, maybe to sort of abstract the role or some other attributes from that. Also looking at transactions and logs to see, you know, which cases might benefit from being a, a permit default versus a denied default and then scalability and, you know, authorization can kind of be compute intensive. So when you're deploying a, an aback or a policy based access control solution, you'll wanna keep in mind what you think your absolute maximums are for authorization events per day, per hour, per minute, and build for scalability.
So how do we do address scalability while there's, first of all, the question of what protocol do you want to use, or what protocol can you use given your existing application constraints? And then there's always the possibility of adding hardware and load balancing. And then now there's also, people are beginning to think about how to move authorization to the cloud, just like anything else. And I am eventually things can be split off as a service. Authentication's a good example. Now there are lots of good products that allow you to do authentication strong authentication as a service in the cloud. And I think we're gonna see more of this kind of thing with authorization and, you know, fine grained access control, the decision process itself, being moved to the cloud.
So running a little short on time here, but I will, let's take a quick look at the different protocols I SAML isn't typically associated with authorization. It's more of a Federation authentication solution, but you know, if you build in attribute lookups and package that into the Samal token, you can do some authorization and access control with it, but it is static. For most part, you don't get the dynamic lookup that you do, let's say with exact OAuth or jot tokens, but each one sort of has pros and cons associated with it. Exacts can be difficult to deploy cuz it's complex. And there aren't that many products that support that, but it is, you know, almost infinitely flexible in terms of policy O as we were just reminded can have security issues if not implemented properly, but in general, it's easier to deploy. There's a lot of product support in jot. Token's a little bit newer again, you've gotta get the security right when you deploy it, but it's also quite flexible. And each one of the, the last three, there does permit more dynamic lookups.
Then lastly, I thought we'd take just a minute to look at the different business drivers for authorization on the finance side, step up authentication, step up authorization for transaction approval. That's a pretty clear cut use case. You know, you'd want to be able to stop someone from fraudulently, transferring large amounts of money. So if you can introduce some friction to the user experience that might be helpful. So transaction approvals a, a good consideration there, inter organizational collaboration, you know, I think fine grain access control or the lack thereof is one of the things that really hampers organization's ability to get together and collaborate on projects. If you have to build out a new collaboration space and, and give users different user IDs and assign entitlements and different systems, and they tend to get out of date more quickly, it, it just increases the cost and decreases the usability of collaboration environments, unless you have a really good authorization solution.
So I think this is a, a huge driver for authorization going forward, controlled visibility. I think healthcare is a good example here, you know, as a patient, you want to have control over what you see and what you share with different doctors. So, you know, depending on the context of an information request and, you know, different people should be able to see different things. And then lastly, API, everything as applications begin to talk more and more to one another over APIs, the authorization needs to take place between applications. So, you know, an app to app authorization event would be something that would fall under this category. And, and just as user to application or device access application to application authorization needs to happen as well. So with that, I'd like to turn it over to gal.
Thank you, John I'm gal, I'm the chief innovation product at plane ID. Plane ID is the authorization company. John just spent the last 20 minutes speaking about the authorization as they will till now giving a, a good overview and description of the solutions that we saw in the market. I'm going to speak about the future of authorization, where authorizations are adding, and pland being a leading company, being the authorization company, providing those solutions. So in order to answer that question, let's start by seeing what are the main business drivers for, for authorization. And it starts with, first of all, want to say that we see a lot of changes in the market. We see change in the discussion because if we used to hear the question, why do we need that? Why do we need even authorization solution today? We hear a different type of question, which is how is that done or how can they make the process much more efficient?
And the reason is there are many different business drivers like privacy controls the need to collaborate the need to share data, the need to provide governance, the API economy, all of those are driving the need for better control and visibility control and visibility over data control and visibility over the assets that you want to enable access within your organization. So it's not just technology that drives forward authorization, but also the business. We see legal department, we see compliance, compliance, and control. We see the risk department asking for a better solution, a better solution that would enable them to control that would enable them the visibility into the data they are responsible for. And those are the main business drivers today, today in the market. Now I want to go back to the authorization question. So John touched that a bit and they would like to elaborate a bit.
So the authorization question basically needs to answer who can do what and when, right? That's what we want to do. We want to connect identities to data. We want to connect identities to functionality. And in order to answer this question, let's understand it a bit. It starts with the who, who are the identities that we want to enable access to those identities can be our employees. They can be our partners, external users, even system accounts, wearables, basically any identity, any digital identity that operates within our digital landscape is an identity that requires authorization an identity that we need to approve access to data, to functionality. How do we identify that identity? Right? So an identity typically was identified just by a unique identifier, the user ID. But today we know we can identify identities by a list of associated metadata attributes. For example, if this is an employee, an employee has a title, an employee has location within the organization.
An employee maybe has certification levels, all types of metadata associated with that identity that would enable us to make a decision in a much more efficient way. So those would be the first set of attributes. The first set of metadata that can participate in the decision. The second set is what is being access? What do we want to protect? Or what do we want to enable access to? It can be financial records. It can be medical records, it resources, workflow, objects, whatever, whatever objects of data of information you want to protect, those would be your assets. And also they have a list of attributes associated with them. So let's take an account record. For example, an account record has maybe a type a classification, maybe a location it is associated with, again, a set of metadata, a set of attributes, which we can use in the access in the access decision.
And lastly are the environmental attributes. They affect the, when the conditions, which we want to place on the policy, on the access decision. And that can be day and time. We want to enable access only from eight till five, Monday to Friday, or location only from office only from home or maybe both or for my mobile and so on, but they can also be much more interesting than that. Let's say we have a risk based system and we want the level of risk to influence the type of decisions, the type of access decisions that we are currently doing within the organization. So if we are, there is some kind of high risk event. We want to limit access or to enable access and, and so on. So basically all that data, the data which is available at the time of access can participate and lead to the access decision.
And that would be the policy based access control approach. Seeing the attributes, seeing the data, which is available at the time of access, defining the connections, the relationship between those attributes in order to make efficient decisions that would enable access to data, enable access to functionality. For example, let's say I want to enable access to doctors for the patient's records, but I want to do that based on a proficiency based on if the account is currently, the patient is currently active and based on location, one policy statement can cover all of that and provide a very efficient way to control access to that data.
Let's use an example from a different world. Let's say our assets are all those candies and we have all types of them. We have a soft candies held candies. We have, I dunno, marshmallows, eh, red, green, all kinds. And our identities are those kids. And we want to enable access to, eh, our identities, our users, to those candies. How can we do that in an efficient way? We don't want them to just walk to every store and get whatever they want, right? We want to place some efficient controls over that. And those efficient controls might state that if you are under the age of three, you can't have health candies. All you can have. If you have a red shirt, maybe you can have only the red candies, but not after 8:00 PM. You can have that only during the daytime, maybe on Fridays, we want to give access to all types of candies, as much as they can eat.
I don't know, but we have the governance party, which would be the parents as of course. And we would have the shocker, which is the business owner of the data. Both need to place their controls over what candies can be provided to those, to those kids in order to make that more efficient and not just everyone who can walks by can take what he wants. And that's just an example of where policies can, eh, what, what efficiently policies can bring us policies enables us to, to connect our identities based on different characteristics, based on their attributes to the data in this case, the candies, which we want to enable access to. And of course we are not speaking about candies. That's not really our assets. Our assets are form the financial, our assets are data data, which we want to protect. And our assets are clinical functionalities, which we want to enable access or prevent access to.
Those are our policies. And that's where we want the efficiency efficiency to be. So to understand the solution, what should be the solution for our comprehensive authorization platform, let's look at the authorization pillars. The solution should have a, should have a, some kind of, so the solution should, should have some kind of answer to each of those. S first of all, administration authorization should have a very well defined administration capabilities. We want a clear way to define our policies. So John showed you before a policy, right? Could you read that policy? Could you understand that policy? Would you give your business on a Zima policy like that? It doesn't really make sense, right? So let me show you in a second, how a policy can look like away to define a policy clear way to view the policy is an important and EAL part of the administration component in a authorization solution.
Second, an ability to validate and test the policy. It's not enough just to write policies there. What do they mean? How do they affect who are the users affected by this policy, the resources applications. So it's not enough to provide a tool that just enables you to write policies. Administration contains the ability to validate, to test, to analyze your policies, to provide full visibility. What we like to call and end to end visibility into your policies. And that starts with who are the identities, what can they do, and which conditions and applications, resources, and actions that would be your end to end view of your policies. And of course, governance, let's not forget governance policies have the ability in general authorizations. They have the ability to influence dramatically on what identities can do. They have a dramatic influence over the capabilities your organization is enabling.
So you have to have a governance tool around that. You need a way to approve your policies, to inspect them before that a workflow, which is associated with each type of policies. And it can be just one, right? You have different types of policies. You have different departments, you have different business capabilities within the organization. So you would also want to delegate administrative rights. And that is another important aspect of the policy administration of the authorization administration, the ability to delegate the administrative rights of what you are building. So no to that. As part of the pillars, I have emphasized administration, we strongly, we strongly believe that administration is the most important part of an authorization solution, providing visibility, validation, and testing analytic and full governance tools around around policies. Second is the decision. You want your tool to be a smart tool to support your smart decisions.
It should have the ability to take into account any piece of data, which is relevant. If the risk score of the organization is relevant, it has to be taken into account. If the security condition is relevant, it has to be taken into account time of day location, flexibility of the data model, flexibility of the decision should be part of that. We believe that in order to support that you would need advanced technologies such as a graph database that can support those type of decisions. And lastly is of course enforcement, eventually all those decisions that you're managing, you want them to be enforced correctly. And I want to relate back to what John said before. So there are multiple standards today, right there. Isn't just one standout. So what, what, what is the way to enforce access? What is the right way there? Isn't just one answer to that, right?
Because today the reality is that there are multiple standards that supports of authorization enforcement. So, or Zamal even Sam. I know it's not meant for authorization, but it's Dell organizations are using it Jo kins. And you know what? Look at all the cloud vendors, they are building their own new standards, their own new APIs. So you need a solution. Once you look for a solution to authorization that can provide that type of flexibility. I'll touch that more in a second in a two more slides. So back to the policy based access control concept, I'm not here to speak about evolution of authorization. John presented that very well. I just want to emphasize what policy based access control is all about. And policy based access control is not a different name for attribute based. I know there might be some arguments around that, but let's, let's see, what's the difference.
So of, of course, authorizations have gone a long way since the old access control ACLS who are going through world based attribute based, and then eventually where we stand today, policy based access control, policy based access control can a, can support both attributes and roles. And I know, I know you might say yes, role is just another attribute. I know that's, that can be viewed that way, but we believe that role is an extended attribute. It's not just another attribute to look at. It's a unique type of attribute. And you know, why think about why attribute based didn't, you know, didn't catch so well in the market. It's therefore so long, right? More than 10 years, we have attribute based concept in the market. Why wasn't it adopted that? Well, part of the reason, not all, but part of the reason is that you just don't have all those attributes in place.
They are not well defined. They are not well managed or organized or governed. So you must have was that you can't have just one without another. So a comprehensive authorization system should enable you to utilize both attribute based and support roles, roles, definition, roles, management, and roles, government. Okay. So that is wonder differentiation between just being an attribute based system and the comprehensive policy based access control system. The second is the level of control. So existing solutions are focused more on a localized level control, looking at a specific application embedded within a specific application or managing a specific repository policies, policies have a much wider view. They have the enterprise level control view. I can use one policy to influence many, many different points. Look at, let me use an example. Let's look at a Porwal a data Porwal. So a data Porwal would enable access to data, right?
And we would have policies providing enforcement to that data Porwal but same data can also be accessed from the reporting system. And maybe it can be also accessed from another BI system, same data. We want the same policies because those are business policies to be able to enforce same controls on that data, regardless its access point. Right? So that is what I mean by enterprise level control. And the last thing I want to mention here is that policies are not just about fine grained access control. Why? Because that's the reality today in the market policies are, eh, policies have the ability to provide calls, grained app to fine, fine grain access control. So let me use an example. Let's say my policies account managers can access their accounts data, right? That might translate to fine, fine grained access in my internal CRM, maybe using Zima, maybe using job tokens, whatever works for, for me, or it might mean access to adaptive access to Amazon storage buckets using their APIs, or maybe something else.
So policies they have that capability supporting all those types of authorizations. How are they supporting authorizations? So multiple standards, like I mentioned before there, isn't just one way to speak authorizations today. Most of the market is still with security groups, right? That's look at, look at what you have today within your organization. Most of that is security groups. Don't you want your policies to be connected to that, to be controlling that if the aim is to provide visibility and control, it doesn't really matter how, because that's what the technology dictates. Yeah. So we can do that in multiple ways. It doesn't matter the underlying technology and that leads to the solution. Okay. So let's look at that. So the solution should provide a master policy layer, a master policy layer that enables both the business and the technology, a master policy layer that enables you to write your business policies in a way which is understandable and accessible by the business owners account managers can access their accounts data from eight till five, Monday till Friday, the doctors can access only patients for of their proficiency from only active patients and only from their office, maybe also from their home developers can access development, specs of their projects, right?
Those are policies I can. And I, as a business owner can understand, can approve and consult. And those policies can translate to all those consumers, whatever protocol, whatever authorization language I want to use. And as I mentioned before, I'm going to give a small taste of a policy, a graphical policy. So remember what John showed you, the Zamal policy, the one you couldn't read. Okay. That's a plane ad policy, very clearly showing data Analyst and agents and account managers can manage commercial accounts. What does it mean? Manage commercial accounts? Look, it says right here, you can view and you can edit all active accounts. Okay. And if there is a condition again, very clearly it is presented. The graphical representation of the policy is the way to express those decisions in a way which they'll understandable and accessible. Okay. I'm kind of running out of time going to be speak a bit faster.
So one last thing, it's not enough to just provide an enforcement for those policies. The tool that you should be looking for to manage your authorization should have full life cycle management support should have the ability to delegate authority rights and should support whatever type of functionality is required in order to manage better. And in a more efficient way, your authorization supporting a detection phase, because you don't always know what are the authorization data that you have in place, right? It's not always there. It's not always visible supporting the ability to evaluate policies. John mentioned that machine learning big data analytic to assist in building those policies in an efficient way. And then lastly, of course protecting, but it's not enough to have just that one layer, a comprehensive authorization solution should support all of that life cycle, which is required. Last, last slide. Let's see what is changing.
And then we'll turn over to questions. So authorization used to be the, the soil property of the technical O owner technical owner, right? The ad admin. He controlled the policy, controlled the access. He wrote all the active director groups. He added users. He controlled everything, but is that enough? No, no. Today we see that business owners, they need the control. They're requiring the control. They want to see who can access their data. It's their responsibility. If I can approve money transaction, that is not the technical owner responsibility. That's the business owner responsibility. And you know what? They don't want those reports in an email, which we are sharing each and every man folks. So it doesn't make any sense. They want to see that when they need the data. And that leads to the market itself. Authorization is taking its place as a very legitimate part of the overall IM landscape. It used to be just identity. Then authentication took its place and now authorization the same way as you have in your organization today, author authentication as a standard authentication as a service within the organization or in the cloud, same thing for authorization. You should have a standard for authorization. You should have a solution for authorization for each and every application that you're onboarding. Thank you. I'm gal from plain ID. Plain ID is the authorization company, and we'll be happy to speak more about what we do feel free to approach us. Let's turn to questions.
Thanks. Go. Okay. Let's see. What do we have for questions here? Yeah, I think before we get started, I think it's a good point. You know, you were showing in the how to sort of use the gooey to make it easier to build policies. That's another, another good way that a lot of products in this space are you give you dropdowns and things like that, to be able to sort of put it together without having to know the details of policy languages. So let's see. First question. How has policy based access control actually assisted a customer? Do you have an example you would like to give?
Yeah, sure, sure. Absolutely. So from our, one of our customers, we have, we have been asked to, to look at the current set of walls, which they're managing and they have provided us with several thousands of wall sets. That's the way they manage it today. And the main challenge there was for the business owners to be able to govern that, or, you know, to even answer the question of who can access what, so taking those set of rules and understanding what we call the policy building blocks, you know, that's the first stage of building policies, understanding what are the building blocks, the components, the decision should be built on. We have been, we have managed to convert all those rules to several hundreds. So first of all, Matic decrease in the amount of decisions which have to be managed, that would that, so that enabled the, the business owners there to first of all, start seeing the decisions and managing them in a more efficient way.
Second, because we use the policy based approach. They were also able to see for each and every decision, how it's affecting the identities, how it's affecting the resources themselves. So it's not just like, you know, a technical statement written somewhere that doesn't really make much sense. It actually brought much sense into, into the whole process and it enabled them to address also some of the audit requirements, which many organizations are required to, to follow. So, so that's, that's typically how policies can assist organizations. First of all, efficiently efficiency, sorry, the ability to take an existing set of definitions and reduce them dramatically to a limited set of policies. And then based on that, provide better visibility on the effect of those policies.
Great. Next question is how can, how complex can your policies be
As complex as you want them to be? And I was offering to try take the most complex policy you can think about and see how that actually comes into a better visibility using the graph policy, because we use a graph database to model the policies that enables us to support any level of complexity for the policies you can bake, sorry, you can build different conditions into the policy and you can create relationship between any of the groups of attributes you want to participate as part of those policies.
You know, I think I would add to that too. You, you can make them quite complex. Some of the details of which probably depend on the, the protocol that you're gonna use as well. You know, I would, I would think of something like exact bull as something you could use to build extremely complex policies, you know, more so than, than probably ooff. But at the same time, I would, I would recommend not making them any more complex than you have to make them two for a couple of reasons. One is scalability. Every lookup that you do is gonna add, you know, milliseconds to the response time. And then also availability if for some reason you're drawing information from a lot of different policy information points and one or more of 'em for some reason, become unavailable. Then depending on how you've written your policy, if it's mandatory to get that bit of data back then you can, you know, stop work from being, being done because you've built a, a policy that may be more complex than you really need it to be. I would just say, keep those kinds of things in mind when you're building out your policies.
Yeah, I absolutely agree with you. Absolutely.
Well, let's see. Next one policy based access control and IGA, do I still need IGA solutions?
Okay, well, that's an interesting question. So my answer would be of course you would need an IGA solution policies. They do not replace that. They don't provide provisioning. And the whole purpose of IGA is to look into your repositories, right? And, and govern that and provide provisioning to those repositories policies. They can sit on top of the IGA and they walk very well together, right? Because policies, first of all, they provide runtime. We, we haven't really spoken about the overall policy based framework in, in this webinar, but it overall framework would be based on both runtime and admin time authorizations, right? So the policies, they, they have the runtime capability as part of what they provide, but they can also influence the admin time decisions as well. So that's why I believe those two would work very well together. It's not a replacement though. So policy, the policy based access control approach does not replace the classical IGA.
Each has its own very good place and, and set of capabilities they would need to address. But I would suggest that you would think about walking together, combining those two solutions as you move forward in order to support in a more efficient way, the overall management of authorizations throughout the organization, because we, the current repository base, the current meantime authorization is not going to go away. It's them. You might want your new applications to walk in a different way, but you also want to support and to provide that centralized control for all together. So that would be something to consider.
Yeah. You know, I think optimally, you would have both, I mean, if you're in an environment where you do have to have complex authorization decisions and, and more and more companies find themselves there, you know, as we were talking about earlier, the proper functioning of an aback or PVAC system depends on the underlying quality of the attributes. So IGA solutions, you know, the ability to cut off access to somebody when they leave, or if they move from one group to another, they no longer need access. It really the proper functioning of a, an access control solution really depends on an up to date identity infrastructure. And IGA is a really important component of that as well. So I think both are needed to, to really do things
Properly. A absolutely absolutely agree with that. Yeah.
Okay. We've got one more minute left, kind of an open ended question where to start.
Oh yeah. That's a good question. Where to start, well, start by understanding what you currently have and where you building to. Sometimes it's tempting to start from the enforcement. I mean, you want to get that done right away and look at this one application, but I would suggest to start by sitting out of bend aside, letting the, the product that you choose to look at your current authorization landscape and start suggesting policies start, and they'll standing the current data. And then from there building your internal authorization as a service, right? For any new initiative, any new applications, eh, cloud of course must be part of that. It's not efficient to go back and try to change everything. It won't really work, right. You want to, to build a plan to support all new initiatives and provide better control for what you currently have. So that certainly requires a plan. So that's, that's my, you know, my, my, my way to, to start working on those type of projects.
Okay.
Yeah.
Well, thank you. Thanks for everyone attending and, and thanks golf for doing the webinar here with us, and we will get this up online within the next day or so, and look forward to joining you at future event or one of our future webinars. Thank you.
Sure. Absolutely. Thank you. Thank you very much.