Good morning. Good afternoon. And good evening, depending upon which region you are in my name's Graham Williamson, I'm an Analyst with CAPA Cole and I have the privilege of introducing this webinar today. We're gonna be looking at fine grained access control that we can do with the axiomatic product. My introduction is going to be of a general nature looking at what are some of the issues we need to be concerned with. And in particular, how do we manage those issues where there's a legal requirement to control access, to protected resources. Then Dr. Truth ne is going to be talking in more specifically about how to make this process as frictionless as possible. So do hope that you enjoy this present the webinar today in terms of KAA Cole and activities. There's basically three activities that KAA Cole is involved in research services is something that Capol has been involved in for many years now.
And if you're not familiar with the research repository, go onto the Capol site, click on reports and look at the reports that are available just on about any others, any topic you might wish to concern yourself with in identity access management and cloud migration, then there's the advisory services. If we can help you at all with the activities we talk about today, we very much appreciate doing that for you. And thirdly, there is the events and the largest annual event is coming up in a couple of weeks time in Munich, Germany. And if you haven't been to an EIC before, it's definitely an activity to be part of. And we would hope to see you there. There's advanced warning in regard to the digital finance world in September. So if you are in the finance industry or have you had an interest in that space, please mark that in your calendars, in terms of the webinar, you're gonna be muted.
Unfortunately, there is too many people for us to have an audio activity, but there is a question and answer session at the end. And please, if you have any questions as we go along, type them into the question area in your control panel. So bottom of your control panel, there's a section there for questions type those in, and we will get to those at the LA LA last part of the webinar, the webinar is being recorded. So you'll get notification of the location of the podcast coming out to you in a day or so's time in terms of the agenda for this webinar. I'm going to, as I said, look at the, the business case and legal case for moving into an adaptive policy based access management environment. And we've taken that terminology and we've chosen it quite particularly. A lot of people say AAC attribute based access control, but really it's more than that.
It's adaptive. That means that it's dynamic as attributes change decisions, change is policy based. So rather than having our access controlled by our roles, our access is now are now controlled by attributes that are based on policies that we have established. And lastly, it's access management is not just control. We are able to provide a much more fine grain management of access. If we move into this authorization base, then in part two, truth will talk about the policy analysis activity. How do we actually do that? How do we manage our policies and what tools do we have to make the policy management easier for us? So there's a new product that Axios have called the review manager, and truth's going to be actually showing us some screenshots of that particular product in terms of the identity and access management environment. This screen sort of tries to capture all of the, okay, our organizations are made up of people. So we need to obviously be able to manage all of the identities associated with our organization. And that goes from our staff to our contractors, to our business partners, to even to our customers, we're dealing with people and we need to manage the attributes associated with our people as we are granting them access to protected resources, but people use devices.
Our
Staff, for instance, want to connect to our services. It's not just a PC anymore. They often connected with tablets or I like that term tablet. Okay. So they've got other devices that they are going to attach with, and we need to keep that in mind because indeed we might have different rules depending upon when they're connecting from a PC on our corporate network, to whether they're connecting from a smartphone, the attributes for this connections together and say, oh, that's high risk for me and act accordingly. And then of course there's things we do need to be able to manage things. We hear more and more these days about being able to attach devices to our network, that monitor things, or allow us to control things. And so we need to associate those things with the people in our organization and know what those relationships are. So this screen sort of captures the breadth of the identity and access management environment. And indeed, we're going to now talk about how do we manage that with an attribute based policy based management system.
I, I often think back to the good old days when applications had an access control list. So if you wanted access to a particular system, you just needed to go to the system manager and say, please add me to the access control list for this application. And then you get access to it. The problem of course, with that is it's very hard to manage is very costly. And there's a security issue because oftentimes people never told the system manager when somebody left. So they were never removed from having access to the application. So then we went into the roles based approach and organizations said, look, if we, if we actually provisioned people into application based on their roles within the organization, that makes it easy for us. So we know that a finance manager should have access to the finance system and other systems. And as soon as somebody joins as a finance manager, we can do that provisioning that works well provided.
The applications are capable of, of being managed that way. A probably a more common role based access control approach is to use ad groups, sorry. People in the finance department get put into the finance ad group and they can then get access to the finance system. And we can have another ad group for managers in the finance department, give them extended access. So we can do that through, through through groups. And many organizations are still doing that today. What we're talking about here is going that next step of moving into an authorization mechanism where we say, okay, this person is joined the organization. We will give them such and such access, oh, by the way, they are a finance manager. So we then provide them access to the finance system at the appropriate level based on that attribute. And that gives us a lot more fine grained approach because we can then say, okay, well, as we are providing access to the finance system, if that access is from a smartphone and it's the middle of the night, maybe we'll treat that with a little bit higher risk than we would if it's access from our network during the daytime.
So we have a far more fine grained approach then to the access that we can give to people connecting to our, our, our protected resources. So in this, in this way, we, we are truly putting together an authorization mechanism where we are dynamically deciding what access somebody should have to our resources, the, the, in getting to that type of system. I wanted to just emphasize that we are talking about being able to have our applications recognize a, a, a situation that's evaluated by an external decision point. So we have to have our applications to be able to accept a decision that's being made externally to the application itself. We have to have a central policy management capability. So we have to have the ability within our organization to establish policies and manage those policies more about that in a minute, but that does then give us the ability to do this far more granular decisions make, make more granular decisions on, on what sort of access we're going to provide.
So we've talked about identity attributes, and we've talked about context attributes, which can be the time of the day. It could be the device that's connecting from. It could be the various attributes that we, we want to evaluate from that point of view, because that isn't, those are important for our access decisions. I know of one organization that restricts access based on geolocation. So if somebody's connecting from a particular geographic location, they will treat that access request a little differently than they would if they, the person is connecting from their normal or corporate location. So we, the, the attributes don't necessarily just have to be identity attributes. And in doing this, we avoid role explosion. So the, the, one of the issues that organizations have with a role based access control is the propensity to establish a role for each different type of access entitlements that are, that are required.
And so you quite easily, it's, it's very easy in those circumstances to have many, many roles that are then become hard to manage. And I want to illustrate that with a healthcare use case, the situation that was, I was involved in a couple of months ago, what we did in this case is we looked at the environment and decided that the roles for healthcare personnel could basically be put into five groups. So we had five role role types. Obviously we have doctors and nurses, but there's many healthcare professionals that don't fall into those two categories. They are providing healthcare, but in a specific sort of area. And so we group them into a group called health professionals. And then of course, there's the administrative personnel. The administrators have a clinical position, but they do need access to systems because they're managing people in that area or managing devices.
Common one is managing a staff routine and they need to be able to go in and do that for, for anybody that fell outside of those four role types, we put them in other, so these are the people that need access to systems, but they're not providing healthcare, not are they really administrative? They, they need, for instance, technicians or, or, or a patient care officer who's moving patients around hospital or, or a clinic. So those type of people, we, we grouped another. This was a way of, of managing the, the roles. And then if we take a look here, this is just a very simple, small piece of the much larger amount.
If you, you are in emergency department, the consultant or the, or the registrars can do things that the residents and interns can't in terms of managing people, the, in the radiology system, the access to whether you can order a radiology scan or whether you can view it. And if you can view it, do you need to witness it? These are all different entitlements that you have within the radiology system. And then in the medical record system, the, the consultant registrars, they move between different locations. So they need to have access to medical records at all of those locations. However, if you're a resident, you're at one acute care facility and therefore only need to access to the medical records at that particular location, the EHR is electronic health record, and you can see everybody gets access to that. That's because the electronic health record system actually manages access to the patient records based on patient consent.
So it's got some internal capabilities built into it. So you can start to see here, some of the legal issues that we have when we are providing access to a sensitive information, such as a Medi medical record. One last thing I'd like to point out from, from this, on this slide in radiology, if you're a doctor and you are a radiologist, you get very special access to the radiology system, and you can do things in that system that others can't. So I hope you can see that just from this one area, the role explosion is quite evident at how, if you're trying to do this on a role based approach, it becomes quite complicated. If however, you take an attribute based approach, then obviously you can accommodate the radiologist. Because as soon as you, you see that somebody in their identity record as a radiologist, you can then turn on that capability within radiology.
So the attribute based system gives us a mechanism for controlling that a little better. Just wanted to put up this slide just to make sure we're all aware of how we need to manage an attribute based system. Typically the resource, which would be your protected application in this instance needs to have an enforcement point capability. I talked earlier about making sure that if it's a legacy system, for instance, we need to have this enforcement point built into the application because it's, that, that actually does the request. So when a user accesses the resource, the policy enforcement point sends the request to the decision point saying this person's trying to access this application at this level, is that permitted. And the decision point will then come back with a permit or a deny. If the rule set can't be evaluated, it will give you an indeterminate.
So there's a number of options there. But what we're looking for is a permit to come back to say, yes, I give this person access to this protected resource. The policy administration point is something that, that SIF will go, is gonna be talking about to, in terms of how do we set those policies and how do we make it as frictionless as possible. And of course, this whole thing does presume that we have the access to attributes that are held in, in, in an information point and does then presuppose that we have a relatively mature identity and access management environment that allows us to capture those attributes and then leverage them within our access control mechanism. The benefits we've talked about, okay, obviously having a centralized policy management capability gives us consistency. So rather than having individual applications decide how they're going to, or, you know, based on the, the access control list mechanism, we have to have each application make its own decision.
And those, the, the, the overall policy of how the organization's govern then becomes very difficult to do with a centralized policy management capability, particularly if it's being managed by the business units. And that's what we would recommend, then we have this consistency and that gives us improved governance. If we've got improved governance, it means that we've got a single policy administration point that we can, we can use to make sure that those that are granting access are accountable for the access that they, that they are being, that they're built into the policies. And lastly, the agility in a very important one these days, if we have the, we, if we're basing our, our decisions on attributes, as soon as an attribute is changed, the next time that policy set set is evaluated, the decision will have changed. So this gives us the flexibility to, to be able to accommodate changes in our organization.
And as we all know, those are happening faster. And for, in terms of then the challenges that we have, we've mentioned the legacy application support, and having this enforcement point functionality associated with our applications, most vendors will provide that the enforcement point code that you can just build into your system. Okay. So that's something that does need to be done in terms of the policy governments. You do have to have the ability within your organization to manage those policies. And we recommend that that gets devolved to the business unit. That's managing that particular situation. It should no longer be an it system administrator granting access access should be based on what the business units are establishing as their policies for access. And lastly, the policy administration has to be put in place. So we need the ability to be able to evaluate a policy set, to determine what the, the access control response would be under a certain set of conditions. And we need the diagnostic tools to make that policy administration as frictionless as possible. And with that, I'd like to turn over to SHR, he'll be talking about then how do we do this policy analysis? And he's going to introduce us to the axiomatic review manager.
Thank you very much, Han. So thanks again for the wonderful introduction to our, of in your case, the specifically the whole copy, a call defines as the policy based access control management. So what I will do is take that example of hospital and, and the administration within the hospital, and take it a bit further and show how certain things still needs to actually make sense from a administration order to compliance point of view and how axiomatic products can help in that. Before I go into the details of that, though, if you don't know axiomatic as a company, I thought I'll give a quick introduction to axiomatic. We provide enterprise software for access control that our bread and Barto, we do access control and specialize in it. And AAC and policy based access management is the core is in the core of all the things that we do.
We have shown thought leadership in the Abbe technology, the standards we have been involved in the standardization work from the exact mobile standard, the extensible access control market language, which is one of the core standards of AAC and attribute based access control from the OSS standards committee. We are also been involved in the actual standards, writing process, editing process, writing profiles, which extends the standards to different aspects. For example, the, the adjacent profiles of thel standard and so on. And we try to innovate to meet the new demands that our customers put in front of us because of their requirements, because of their requirements of the change in technology. They, they go through and so on, and we try to make it simple and do implementation with low TCO, total cost of ownership. And that's behind everything that we do from a company point of view, our customers range.
We, we have fortune for hundred customers within the us, the European markets. We have federal government and local government agencies as our customers, and we have vertical market expertise, be it from the, the financial service, double banking insurance, re insurance kind of environments, highly regulated industries, farmers, aerospace, automotive, where IPR and all the issues related to confidentiality is very important. We have dominated industries, as we mentioned within the, the federal side, as well as the local governments in both the us and the European sectors. And we have media companies who's involved in providing media to be, be, be to see customers basically. So as you can see, we have a wide range of customers. And the, the reason we brought that up as a slide was to show that we get a lot of inputs from customers from different angles on the requirements that they have in their environment, in the industry that we they work at.
For example, if you look at the highly regulated industries, they have strict requirements on what's possible. What's not possible the complexity of the rules that they need to be able to enforce. And as Graham mentioned, even if you look at simple cases of sharing data across people within the same organization, but within different clearances, like doctors and registrars and consultants, and add in the mix of different departments, you can see the complexity actually evolving pretty quickly. And the attribute based model allows you to enforce that in a very easy manner, in a manner that can actually scale from a solutions point of view. Aromatics has got two basic buckets of solutions to basic group solutions. What we call the authorization for applications, which is what Graham actually kind of refer to from the different EPS, the policy decision point and the policy information point. That's very logically what we do from authorization for applications.
So if you have a reporting application or a CRM solutions or a document management system solutions, and you wanna write policies against how who can access what resources and do what, whatever specific actions, that's the solutions that you'd be looking at authorization for applications. So it's at the business logic and the APIs web service level, and then you have the authorization for databases. And one of the things that we realized when we'd worked with customers is that even though we do a lot of access control at the business level, at the UI level, even, and at the other different stacks, a lot of the data, a lot of things of the things that you're actually trying to protect finally sides at the database level. So we moved the policy enforcement point that Grham was mentioning in the slide closer towards the database, so that when you try to access data from the database, be it, what will be the application that you have, you actually have to do access control as close to the database as possible, which means you can actually separate out the enforcement, find away from the applications and move it to a slightly more central place as well.
So, as you can see, we have looked at all the different scenarios that our customers want. And we have customized solutions based on the requirements that we have seen growing in the field of AAC and policy based access management, but still once in a while, we do come across customer questions that kind of makes us think of what next needs to be done, to make that journey towards AAC, as frictionless as possible, and to actually remove the frictions when it exists. And once such question was, we need to be able to do audit and access review regularly. We need more audit and access review capability. Of course, audit in this case is not just about audit from a logging point of view because you can log the decisions you can decide. You can figure out exactly why certain thing was allowed and not allowed a priority or after the fact based on the logs itself.
So you can actually do a lot of audit based on the log, but the, the auditing that they were talking about, the customers when beyond that, it, it bordered on the access review capability, which was around the fact that when you have a clear cut access control list, that Graham mentioned long time ago, when you started off with simple access, it, it was easy for you to take a look at that access control list and say, okay, Mr. X is able to do this specific action, right? This record in that directory or in that database. So it was relatively easy, but then the more, the moving parts, the more complex it becomes to do that analysis. And that's what the customer was telling us. Customers rather were telling us that we need to be able to do that in a more seamless manner. So axiomatic already has one part of that figured out long from for a few years.
Now we have a product called Matics policy auditor, which basically allows the customer. Who's writing the applic, the policy to figure out the gaps in the policy creation process by comparing them to the business or it access controlled policies. So typically most customers start off with an access, an access control requirement, which is driven from an it policy or a business policy or irregulatory policy. It's never ever a policy, which is contrived from a technical point of view. It's almost dependent on certain other requirements. And that's what we call the business or it level access control policies. And then you translate that into a technical, whatever language you use in this specific case. It WASL, you need to be able to understand the gaps as to, okay. Was there a gap in my implementation of what the business Analyst wanted or the legal requirements guys wanted?
And the policy auditor allows you to actually do that kind of a gap analysis it's used to explore and analyze the access control policies during the authoring process and implementation process. So you could basically have a set of reports that's created every time you make a small change into the policy, that report can kind of cover all the different corner cases, all the different invading, the grass policies, all the different specific overruling policies to make sure that everything that you had in mind is codified in your policies. You can test and the policy, all those can test that policies that are being doubled to understand they're providing the expected results, that there are things that those don't slip through the cracks. And you can also test complex conditions, functionalities that are typically not possible in the other products in the market. One of the simple examples that we talk about when we talk, talk about the capabilities that we have in the policy auditor is the ability to ask about negative conditions.
So in the case of the example that Graham mentioned from a hospital point of view, consider a case where he wants to know what are the things that somebody who is not a consultant or who is not a registrar can do in the radiology departments. So you have these negative conditions, which are typically harder to express in, in an AAC world from a policy point of view, because you have lot of different ways in which you can represent it. The state's explodes of all the different options possible and so on. So the policy auditor gives you a, a nice set of capabilities to figure out what exactly a person who is not a registrar is able to do from a cardiology report, for example. So that's what the policy auditor does. And as you can see, basically what it does is if you can ask questions, like, I wanna know what supplier can do within a company network.
Like if you are logged into the network and a supplier, not a person, who's an employee of that network company itself, but a supplier to that company, what can that supplier do? So you ask the query to the axiomatic policy auditor in a slightly technical way, saying something like subject ID or subject role equal to supplier. What are the different actions that can be performed on resource inventory data? And the policy auditor basically looks into the policies, figures out all the different branches possible in the evaluation process and sends back a specific set of answers. That's possible about it. Now, this still does not cover the access review capability. And that's where axiomatic has come up with a new product called the axiomatic review manager. And that's one of the key capabilities that we have in the product. It's a very recently launched product officially.
It was released about a week or so ago. So you are one of the first to actually understand the details about it and know about it. So if you are interested to know more about it, please do contact us further down the line. This is just a quick introduction of all the capabilities that we have right now. So the need comes from the fact that information, security officers, compliance officers. And so on. Want to know if the policies in place in production in your actual system are imposing, what's supposed to be doing because they wanna do support checks. They want do frequent audits. They wanna do reviews in a very frequent manner. And so on another example is a manager needs to sign off on an access review report of support needs that he's in charge of. He wants to be able to take a look and say, okay, this looks correct and signs off every quarter or every half a year or every year.
So you need to be able to provide that. And that is relatively hard to do when you have a lot of moving parts as the victim goes, but great work capabilities comes great responsibilities in a way, because there are so many powerful things you can express in your policies. You get to have to prove that these policies actually does what it's supposed to be doing. Application owners who are completely in charge of a specific way, and application works, needs to know what kind of actions can be performed by various kinds of users of the system and so on and so forth. So if there are different kinds of personas who would be able to use the system. So the review manager basically allows users to understand the effect of the deployed policies it's developed specifically for the use in a production environment, which means it can fetch the L D data trade data about the specific users role.
It can look at specific actions that's being performed by a user, in an production environment. And it can actually look at policies which are actually deployed in a production environment. It's template driven to produce tailored access contributes. The idea being that you write your template. Once you can run that multiple times as frequently as you want change the input to these templates, to kind of customize it to the specific question you have in mind. And I'll give you a very specific example in the screenshots that's coming and provide answers to common questions. The typical questions that we tell as examples are, who can perform what actions on a specific results or any other convention of these variables. So what can adds do, or who all can do the edit operation on that record of the patient data, for example. So all these permutation combination of questions that you have are possible to be quest queried about and, and a report can be generated based on the policies and what the policy allows you to do these report basically at the end of it, aim is to make it helpful, to prove compliance with different regulatory requirements and enable periodic access reviews with internal stakeholders.
Going back to the example of the manager, being, having to sign off on all the rights that's given to the subordinates, that's kind of basically proving to the internal stakeholders that this is exactly how the system should be modeled, or these are the rights that should be given to the users and so on. So the way it typically works, I know it's a bit of a big set of diagrams, but it's very simple to explain you have this authorization service that Graham was mentioning the policy of decision point, the point where the policy gets evaluated, and that uses the policies which are deployed, managed by the policy administration point. So I don't show the policy administration point over there, but basically that's used to deploy your policies and the authorization service, the PDP in this case uses up all the whole lot of information from the attribute services be its databases from the cloud, from a rest web service interfaces could be from an L D or active directory service and so on.
So you can basically use any kind of information source and use that. And what the axiomatic review manager does is to actually query these authorization services, to ask complex question answers, which are open ended. Oh, by what, what I mean by open-ended is you can ask a question that what are the conditions under which us array can access sensitive data? And if you have a policy which says a user can view data of its own department, if the clearance is greater than the documents classification, you could basically ask, say that you could find out the USERRA role in this case, it could be, he's a manager, he's a manager and so on and get the department and the clearance, and you get back a report saying, this are the, these are the exact things that a user a can do. So you'll see that a lot of the magic happens on the backend because the retrieval of the user's role, the clearance data information, the information about the document about the department and all that happen in the back end, without having to know about it from a questioning point of view.
So let me take a, give you a quick idea of how, what that process looks like overall. So how does it work? You first define the requirements for proving compliance. For example, you could basically say you wanna make sure that what a user can view is a requirement. So you wanna make sure that a specific user can only do certain things. And that's the requirements that you have codified, who can view documents of a given classification in this case, then you use that to create reports, templates, to capture that requirements here basically are saying, the thing that's gonna change here is the username of that user. So the valuable thing is the username and the response basically has to contain something about the resource. So he should be able to edit certain documents, not able to edit certain documents and so on. And once that template is created, you can start create creating questions for specific scenarios.
In this case, you're asking about Alice or Bob or Carol. And so basically what happens is you create your query by adding specific values, to that variable that you have defined in your template. And then of course you get back an output, but that the review manager provides. And that's, what's actually useful for you to understand whether the policy is actually doing what it should. In this case, you could basically get a report saying Alice can view all documents in the R and D department. And also only if the document with classification less than equal to secret because that's kind of analysis clearance. So that information that reports that's generated would be very useful for somebody who does an audit compliance testing to say, okay, this actually is what the system should be doing and can sign off on that. Or this is something that the manager can sign off as well.
So the last couple of slides, what I will do is I'll to give you a quick idea of what the, the tool looks like right now, it's undergoing massive changes from user requirements that we get from customers based on feedback and so on. So things are going to improve radically and drastically in the next couple of months, but this is what it looks right right. Now, this is just do data. Just to give you an idea what it looks like it's template driven, which means you can write as many templates as you want. And you can say certain things like, okay, here, I'm going to ask questions about the rules role here. I'm going to ask questions about a specific user here, going to ask questions about certain things that can be done only for a specific record or a document and so on. Now, let's see what that template looks like in this case.
It's a very simple template. It's basically saying, what can the user dash an open a question that you're gonna ask a question about specifically in this case about Alice do with 1, 2, 4, 1, 2, 4 is some idea of a document or do with belonging to patient Bob to connect back to Graham's example. So you can see here that these templates have got things which are static. For example, the username aspect attribute the value of which you provide. And then you use that to ask questions and you get back a response, which can be as simple as this basically saying user Analyst can do certain things with record 1, 2, 3, and here, what basically says, if you ignore all the name space, things is you can view the record. That's the only thing that you Analyst can do. Of course, all the things that happen on the backend is to be able to evaluate the policies, query out to the policy information point, get the attributes, to solve them in the evaluation process.
And so on, of course, this is very simple, but you might have more complex policies and you might end up with reports, which are more complicated, but it's easier to understand because of the way the report is generated. Basically what here, you're asking questions about Analyst. What can Analyst do? What can the CEO Analyst Analyst do in this organization or a manager here, basically you're saying Analyst can basically view any kind of records. So view and records, any kind doesn't matter, who it belongs to. And so on. She can also publish records that are in the final state, as long as the owner is Bob and the actual policy behind it is that Alice manages Bob. So she can publish documents, belonging to people that she manage. So here you can see that the complexity of the policy are exploding and it becomes harder and harder to keep everything in the mind. And it becomes easier to codify these questions into templates that you can then use frequently to get these reports and use these reports to then give it to somebody and say, this is what the application would do. And this is how the access control system would work at any point in time. So that's kind of the end of a quick gist of what the axiomatic review manager does. I'll hand back to, to start with the questions, if there is any, or go ahead with the rest of the webinar.
Super thanks very much. That was very helpful in understanding the current capabilities in the, the review manager system. We, we do have a couple of questions here, so I'll just run through those. We have one saying is the attribute based access control must have. And so, you know, I guess the question is best answered by saying it all depends so, well, I guess the question is no, you, you need to move into an access attribute based access control system or a system that's doing policy administration. And if you do need those, if you do need those services, can you, can you suggest, at what point you would recommend a company moving into an attribute based system from a role based access control? Can, is that something you could just help us with?
Sure. So what, what we've seen is, as you mentioned, Grantham, it's, it's, it's almost always an evolution of the requirements and the needs. So customers typically come from the world of access control and sometimes even white list access control based models. So at some point what happens is that you have too many of these policies that you have to enforce and you end up actually spending more time managing these roles. And as you mentioned, they're all explosion creating too many, too much problems. And sometimes you have requirements where you really cannot express them as based on roles, or you artificially have to create roles, for example, toxic combinations and segregation of duty being a simple example, but it's almost always that in all the industry, so a person who actually created that order cannot be able to, should not be able to approve that order.
That's really hard in some role-based accidental systems to enforce with just roles. And sometimes what happens as you mentioned, Graham is the fact that you have certain aspects related to environment the time of the day, the fact that somebody is within the office network or outside the office network based out of Europe versus Asia, having different access control roles, models. So all that actually complicates the, the role based access control capability. And at some point it just would break down or it's just not good enough. And that's where customers typically move on to attribute based access control or policy-based access control to find better solutions
Super in, in, in the, in the attribute based system that you've described. Are there situations where you don't really need the review manager, if you have a very simple policy based policy set, would you say, do, would, would you say that then in that circumstance, you don't need the review manager? What point do you think you do need the review manager?
Right. So you're right. I mean, if you have a very simple two, three policies or two level three level policies, which depends hardly on data, which is changing, for example, people moving between departments, it may not be the case that you need a review manager, but then as, as one of the things I mentioned again, is that review manager looks at the actual attribute values. The fact that somebody is a manager at a very specific point in time, often doesn't get codified in the policy itself because the policy is written away from a specific users point of view. It says, if you are a manager, do this, the fact that Alice as a manager is a very specific context, time context in this temporal question. And sometimes you just need that aspect captured while the policy itself might be simple. So yes, if you have a static kind of roles, and if you have relatively simple policies that you can take a look at and say, okay, these three policies, I understand, I can see how the flow goes. Perfect. I sign off. And in those cases you may not need a review manager you're right.
Okay. In terms of the, we have a question on, on the, the degree to which you can actually manage access. So the question is, can you go to record level entitlements? Could you just describe the database analyzer that you have in terms of providing access to, to, to a record level?
Oh, right. Perfect. So the, the, one of the products that we have is the ASOS product related to database access control. And there, what we say is, and it it's one of the reasons why we came up the product is that customers want cell level, column level, or role level access required requirements saying something like, if you're a manager, you can access all the columns, this specific column in that table, but nothing else. So the naive way of looking at this is asking questions about each of that cell in that database, which just doesn't scale while the data product that we have can help you write access control policies at the cell level, you can basically look at the column, sell at the role level and not just access, but you can even do transformations because you basically might be able to say, want to say something like, okay, allow access, but Cate or change the credit card into XX until the last four digits and so on. So all that things can be applied dynamically when you access that data. So, and again, based on complex policy requirements that you may have in your environment.
Excellent. Okay. Thank you. We have another question then on the degree to which we, how we deal with entitlements, and I believe the question's asking, is there a central repository of our entitlements? Maybe you could explain how a policy actually evaluates a person's access to a particular entitlement,
Right? So often when you move away from the role base and a very simplified entitlement based model, and this is one of the obvious questions you would have, which is how do you codify these entitlements? And often it is the case that you don't codify the entitlements as such, you try to codify or make it into policy, the business, or the legal driver, which made you do that. Entitlement. The fact that Alice or the fact that Alice can do certain things on a record is not because she's Alice per se, but it could be because she's a manager. And then the fact that a manager can do certain things in the policy, in the database or in any specific regular resource could be because of an it policy. So what typically happens is we look at it, policy, write the policy in a technical way, if, think of it like a simple tree approach.
So you start from one of the roots and then look at the different branches and then says, okay, is Alice a manager? So if you wanna write a policy about managers and normal employees, you would say, if the role is equal to manager, then there's a whole lot of things that only managers can do. If the role is equal to employee, not a manager, certain things that employee who is not a manager can do. And of course you write your policies inside and the rules can get complicated inside each of these branches. But every time there are basically branches coming out of these nodes, and every time the evaluation happens, you go into there, check what are the conditions that this branch question evaluates, evaluation depends on, and then take one of those branches coming from it. So you go down the tree and then you get yes or a no. And then you bubble up and come back with a yes or a no for the specific question. So that's how the policy evaluation would happen.
Right? So that entitlement is co the, the entitlement that I might have within an application is codified into the policy that's being evaluated when I access the resource.
Yeah. And typically as a, as a aspect of the attribute, so an attribute value, the fact that you are, the role is an attribute and the entitlement is the role is equal to manager is kind of the entitlement. And that's what the policy is written around.
Right. Okay. Another question here, can the review manager be used with exact three policies?
Yes, exactly. That's exactly what the P review manager is, is based on we, the way we have worked in this product is that we took it, look at exact policies and look at it and say, okay, how best can we serve the, the market, which is based on a standardized specification, but then extended beyond the standard in answering questions about the policies. So we don't extend the standard in terms of the policy language or anything, but we basically look at various innovative ways of reviewing the policy and auditing the policy's. The central thing still revolves around the standard of exact 3.0, we just innovate around those things.
Okay. Actually another question here on exactly that point, it's missing making the, the, the comment that, you know, this is not necessarily very new. What, what's the requirement that's that's had actually, Matt actually develop the review manager. What did we do before the review manager?
Right. So before the review manager what's happened would be that you would get somebody who's technical, who knows exactly. And sit with that person and say, okay, now show me what would manager be able to do? And then he has to open up the policy editor. The what about editor tool that you have to write your policies in and show how a person who is a manager in this case, if you're asking about a manager would evaluate too and say, okay, if you're a manager, this condition, this branch would be taken. And then you have questions about, I don't know, the clearance and so on and so forth. And there, you basically have to be technical or have somebody who is technical, do things one by one. And sometimes you can of close. Precompute certain aspects of it, but it's apartments way of doing it because you just cannot. Precompute every possible combinations of questions. And then come out with an answer. What the review manager does here is to allow you to dynamically compute those questions, and then evaluate that in an open ended manner.
Very good. Look, our time has gone truth. It's been fascinating time. I really appreciated hearing what you have presented, and I trust that our attendees feel likewise, thanks so much. And we'll see you next time.
Thank you.
