XACML Made Easy: Modeling High Level Policies in XACML

Good afternoon, ladies and gentlemen, welcome to our equipping, a cold webinar, exact or Mel made easy modeling, high level policies and exact. This webinar is supported by EXOS. Two speakers today will be me Martin equipping, a call and FedEx kins from Matics. Before we start some information from keeping a call and some housekeeping, and then we direct dive into the webinar. So just to start keeping a from our Analyst company, we are focusing on enterprise it research advisory, decision support, networking for it, professionals.

Suppose for end user and vendor organizations through subscription services, advisory services and events regarding our events. We have some interesting upcoming events. One will be in internal language, half day workshop at the I TSR fair in Berg next week held by professor Dr. SAS. He will talk about risk and data protection requirement analysis and cloud computing. So what should you do? And what do you need to do regarding risk and your protection requirements in the cloud? The other one will be an end user focused industry round table.

So for refocusing end users about cloud computing security and data protection, again, just German language, we will do the same thing in other languages. Soon. This one will be on in November in Frankfurt. If you're interested, you will find the information at our website. And for sure there will be a letter European identity and large conference next year, the lead conference for these topics. And it'll be in April 17th, twenties in Munich a little bit earlier than the last year. So that's where you definitely should be. And all the information that the UN website way over right now.

So some guidelines for the webinar. So same in our webinar, you are muted central. You don't have to mute or mute yourself. We are controlling these features. We will record the webinar. So the podcast recording will be available latest tomorrow and Q a will be at the end. You can ask questions using the Q and a tool time. We will pick them up at the end usually, or in some cases, if appropriate during the webinar. And so an advice from my side.

So if, if, if a question comes to your mind, just enter the question so that we have comprehensive list for a Q and a session afterwards, like always we will have a agenda with three parts. The first one will be done by me. I will talk about using exact to achieve a top down approach or governance with respect to our a management requirements. So which role does it play there? So we're building the big picture.

And then when it comes to defining business policies and exec mode, it's about Felix then to talk about using exactly to translate high level access control requirements for written written English into exec policies. So that will take, or will take me approximately 50 minutes for my part. And afterwards, Felix will spend some 25 to 30 minutes on his part so that we have some minutes left for Q and a afterwards. So let's directly start X management. I think the, the overall topic of X management is more important than it ever has been before.

So things have really changed over the last years since we have, we are facing a lot of, let's say challenges in that area. One is regulatory compliance, which is about audit, credibility, integrity, authenticity, and all the other things. So we need to, to really be much, become much better in, in, in knowing what really happens and who's allowed to, to what these systems and that does only affect, let's say SAP system, which affect every type of system, all our information.

And that's a very important thing across all the systems in our environment, on premise and in the cloud, we have to deal with these things. We have to risk of data loss, which is whistleblowing weekly leaks, information, security things, which are increasingly important. We have the area of administrative workload, so increasing complexity of environments and, and cars for all, especially when it comes for to, to, to, to the cloud and other things. And finally, we have integration of users.

So how to deal with end use access requests, audit recertification, also integrating users demo and access management really has become a much more important topic. And so, so if you go back some three, four or five years, it was more about IM as a very technical topic today. All these issues are in the mind of the C level of the business user and on, they are really caring about these things. And so we have to react on this, which means we have to really implement technology, but not only technology now, very important thing.

And that is really where we come down from, from governance to what we are doing in technology is we need a methodology. We need to go beyond tools. We need things like a book of rules, which contains of guiding principles, implementation guidelines, core requirements. We need to define the basic concepts like the access management process, re-certification processes, OD approaches and all these things. So we need to understand how to deal with these things.

We need to have detailed concepts and we need to have system specific access management concepts and Important thing here from my perspective is that it's not only about the SAP or host. It's about all the custom applications we're doing about X and all the other thing. Everything works about controlling access. We have to have access concept and they have to follow a consistent approach over time.

So we, we have to move forward towards such an consistent approach, and we need to process an organization structures in there. And then we can really focus on the technology. So it's really not only looking at technology, but the entire thing around this. And this is thing which is part of I am. So where I am really helps them to implement these things, which is a broad range of topics. And I will focus today mainly on a small part of it within access management and then going deeper, where we think is probably the most important single element within the big picture.

So for sure, access governance is a very important thing. So how do I really know these things? And then it's about what do we have to do within this entire access management part? And that's where, what I will talk about only today. So access management, we have several aspects in there. We have authentic indication. We have to what I would call setting access management. So the classical things like we define an access control entry for which says this user is allowed to do debt or something like this. We have the access governance part, which is also laying on top of everything.

And we have what I call dynamic access management. So we have to singes around during runtime, I have to ask someone, is this user allowed to do the things or not? So it's really about this dynamic runtime decisions based on different attributes and criteria provided wrong. One time when looking at these things, we have a lot of different technologies in there. So Federation supports to some degree I can distribute some or can use some things, run Sam to, to ask for attributes.

I, the rule itself, isn't them. What they centralized. It's more about the attribute could be provided from somewhere central. We have privileged access management systems approach for this. We have access management, risk contact based authorization, and we have what we call dynamic association systems. So you also find terms like policy manager or entitlement server there. I tend to use dynamic authorization management systems because that's really what it's about.

It's about having a system, which then at one time makes the authorization system, which has central set of policies of rules, and then decides on, okay, this application, this takes gateway, that SharePoint thing, whatever asks for an authorization decision. And then it takes the attributes and says, okay, that's the answer. I will only cover this strongly. We had some webinars in excite on Phillip afterwards. We'll do a brief, a brief, brief overview on exact on different parts and there. So I don't dive into that very deep during my presentation.

And what is very important was in this context, that's just going back to these big pictures. It's about moving forward to map policies to everything. So when we do these things, the very important thing is we are dealing with one set of information. So we have our corporate information, which we protect, which lies in different systems, which is access using different types of services.

And when we once to cover all these requirements we have for access management, then we should move forward to towards, let's say one set of policies, one approach to man manage access and the approach to very logical solutions. What we see in the dynamic conversation management system. So that also will allow us to have one approach to govern access. So only if we are, if we, we try to, to have more consistent approaches for policy described the same way handled by set of maybe even very, very few centralized systems.

So by standardized approach, that's the very important thing, manage the standardized way. Then we'll be able also to fulfill the government requirements much better than we are today, usually. So why do we need these systems? Why do we need dynamic ization management systems? We need them for externalization. So systems having requesting access decisions from a central instance or dealing with central instances, wherever we, wherever we position the, this instance, PDP, that that could be many Phillip.

Also, we covered it shortly later on, however, it's about saying, okay, we have a set of policies and we don't hard code also say who's into applications anymore. And we don't, and that's even more important. We don't manage all these rules in different ways in different systems, but we have one set of policies or consistent approach, at least for these policies to ensure that information security is handled always the same way we have aspect of context. So taking different factors into account.

I think that's a very important thing as well, a decision, which is saying, okay, Martin equipper is allowed to do that. Isn't sufficient anymore. In most cases it's frequently. The question is Martin are allowed to do that when he uses this device access it access system that way. And with other factors there. So things are getting are becoming increasingly complex. Real world authorization groups don't rely on roads or groups. Only roads and groups are, are very helpful, but it's not that you could rely on this as the only thing. And the most important thing is real standardization.

How to rely on a common set of police, how to move forward to a central place of management and control, not necessarily of execution of decisions. That's more a technical question, but the management, the control, the overview of what is happening there is very important from a governance perspective. So if your auditor today asks you about, about where, where, where do you, or which authorization rules do you have implemented in all of your customer applications?

Probably no one is able to really answer that question or few are, as I've seen our organizations, which have, for example, the mainframe environment are very consistent approach to, to handle these things, but in environment virtually no one. And that's very important thing because these questions will pop up more and more. So exactly what comes into play because it's the standard we have there.

So if you look for a standard for, to do these things, to describe policies, a standard, which has a concept to interface with the context providers, so that ones providing the role information, actually of users, realtime context, whatever, then exact has all about it. When it's about interfacing the applications through PS and PBS, the terms will be defined by a Phillip later on then exact model exact is the standard we have in here. So to do these things, to describe policy, to exchange policies, to interface. So that's where, where really exactly what comes into place.

So if you want to move forward in saying, okay, a lot of different systems in OUS environment use the same set of policies. Then we need something which is a standard, which allows us to do that better. That standard definitely is exact. So exactly will become more and more important as a thing to do there. So when moving forward in that direction, then looking at full perfect exact expectable suite though in that case is a very important thing.

And my, my perspective on an ideal word, really that we are able to use information in based on, on a lot of different services. So that's reality. We have services and services are using information, and we need to be able to couple these things loosely. So that's something we find in Thea environments.

We find in cloud computing, sort of loosely couples things, and we have to lose a couple authentication and loosely couple authorization rely on a centralized set of policies, but being able to loosely couple these things, and we have an established standard sample in there for authentication some part of geo authorization. And we have example there standard for fine grade organization. And if you look at, for example, the cloud to data situation is several providers, for example.

So we can say, okay, I have indicated Martin Cooper, my and Martin Cooper has some attributes I share, but the rules for what this cloud service or what Martin could, is a lot to do with the cloud services still are defined at the cloud service. If I can standardize the policies and manage the policies at my side, then I would avoid a lot of decentralized and hard to audit management for cloud service. And that's, I think the very logical next step. So an ideal word, I would say, I manage my authorization rules. I manage my users.

I manage all these things in these services, just for reliance using security as to service in that case and going back to governance and the rule exactly place they're in. So we have standard applications, customer applications, ML, gateways, whatever they all rely on authorization tools. Some of them overlapping the information they use. I'm not for sure, but we can standardize the way policies are described and use.

We can that enable a bag, which allows to manage policies consistent across different types of applications were required, but also consistent from an audit perspective because that's the, the other part of it. So if you have these things done consistently, you can do a lot of things, much better. That's it's made for heterogeneous distributed environments. That's really where, where we should look at these dynamic authorization management systems and exactly is what really makes these things work with each other.

So when it comes towards moving towards standard authorization environment, then exactly is really a core element is because we can translate business policies into exactly. We can reuse business policy system with different technologies.

We can, which we get information back where we base our audit trails on. We can interface with the context information, and we can especially interface application to applications, to something based on standards that we really don't lock in with the specific technologies, but we are flexible enough to use different technologies if required.

So from, if you look at excite, not only from, from a technology perspective, from the perspective of how do we really manage policies and, and know what happens and know which policies we have, where they are in place and all these things then standard life definitely helps us. And to do this, for sure. It's very important that we are able to translate our business policies. INEC and that's what Phillip will demonstrate right now.

So, Phillip, right now, we'll talk about how can we do this and is it a rocket science or not? And Okay, well, thank you very much, Martin. It's actually a pleasure to be in a webinar with you. And I think this is the first time in many years after having been your colleague for almost three years, we never really did a webinar together.

You know, it was either you or it was me in one of the webinars, but so this is a, this is the first time. And thanks for the, for the vision that you just, that you just presented over there. I think one of the important takeaways over here is definitely the loose coupling between the different services. And when we talk about authorization, this means of course, that we should not be mixing authorization with the application itself.

It doesn't make much sense to, to have authorization code or authorization mechanisms all over the place that, that you can't really administrate centrally, and that are all incompatible. So by taking that out and moving it to, to its own layer, we gain a lot over here. And then of course the question is, well, how difficult is this actually is Zal very complex. I don't think so. And I think that's what I'm going to show you in this particular webinar, that it's actually quite simple, but you have to understand the concepts of it.

And if you use the, if you use Z, as it's supposed to be, it is tremendously powerful in this particular context. So let's get started. I kind of want to jump to, to the example pretty quickly. I thought I will just do a very quick refresher most if you will probably know this, but I think it's worth mentioning this one more time. So what does the Zal standard actually define? We have a reference architecture. We have a policy language and we have a request and response protocol. Now Zamal does not mandate all of these.

For example, you can have a perfectly nice Zal architecture without necessarily using the request and response protocol. You could use another protocol. You should definitely use the policy language. And as you can see, the, the architecture is very flexible. So you'll be using that as well today. Our focus is really on the policy language because I'll be showing you an example of how to pretty much translate a high level requirement into Z mail, but let's just quickly look at the reference architecture.

So user makes some kind of request typically for some kind of information or to perhaps carry out the transaction. So what actually happens over here in our architecture, we have a component called a policy enforcement point. So that is like a traffic light. It will either let the request go through or not, but the traffic line doesn't really make a decision by itself. It just enforces a decision made by another component in this architecture, which is the policy decision point. That's where the actual decisions are being made.

So Felix wants to, for example, carry out this particular transaction, Felix wants to transfer 10,000 euros somewhere is Felix allowed to do that or not? That would be the policy decision point that decides this. And the policy decision point will then transmit the decision to the policy enforcement point. What does the policy decision point need in order to make this decision? It uses information from two particular points. There is the policy retrieval point P R P, where the SAC policies are stored.

And there's also a policy information point where additional information can be retrieved that is used in order to make a decision. I'll give you a good example on that when we, when we get to our, our main part of this, which is the, the actual example last but not least, we have a policy administration point where an administrator can create edit and manage policies. So what is behind the main thing about to remember is that it's all about attributes. It uses something called aback, attribute based access control.

This is quite different from other approaches, such as role based access control, which uses the role of a particular user in order to make an access decision over here, we use a combination of mini attributes and there's nothing wrong with using roles. We can use roles too. Role is one of the many attributes that we can use in order to make a decision. What SAC does. It gives you four categories in which you can define your attributes. It's the subject, which is about usually the user that is carrying something out. It is the action. So what would the action be?

In my case, it might be transfer money, or it might be to a HTTP get Viap protocol, or it could be download something, create an entry view, an entry, delete an entry. Then there are attributes describing the resource. What is it that we're actually doing something on? And my first example, Felix is transferring 10,000 euros. So Felix is the subject transfer would probably be the action. The resource would be 10,000 euros and my bank account. And last category is the environment.

These, this category can be used for environmental variables. For example, what is the overall context of this particular thing that we're trying to authorize right now? Am I connected for example, via a VPN, am I perhaps sitting behind my desk or am I perhaps accessing the system from an unsecured public wifi apps, Rome airport. So these are all things that we can pass in through environmental attributes, what actually happens. So our SAC policies are expressed using attributes of all of these categories.

So we create policies that describe the subject, the action, the resource, and the environment. Once we've defined this in our policies, we can think about a request that is currently being made and that request similarly contains attributes in all of these categories. What happens then is that as we could see in one of the previous slides, the policy enforcement point will send the request to the policy decision point. The policy decision point will then return and answer to the policy enforcement point. Let's go to the example.

Now, the nice thing about Zamal is really that you can almost translate high level requirements from standard English or standard German, whatever your mother tongue may be into computer code that can be executed and audited. It's fairly simple to do this as I will show you right now. And this is quite interesting because when you go to pretty much any enterprise nowadays and you ask, well, please show me on paper, how access control should actually happen in this organization.

You might actually get a few pages of, of clear text, which is described what may happen, what may not happen under which circumstances. Then when you look at how this is actually implemented, you'll see that it has very little actually to do with what was written in the first place. You have all types of different and partially incompatible. It controls all over the place, all implementing some kind of model to kind of put in place, what should really be put in place.

So let's say the high level policies they might actually in reality, be implemented, but there's no easy way to see how they actually correspond because they're all over the place with. It's much easier to do this. Let's take a look at these three rules over here.

There, typical example from healthcare scenario where we have doctors and we have electronic health records of patients. Now this is of course a very privacy sensitive area. And it makes a good example on how you can use these types of dynamic Sacol rules. So let's just read those rules. The first one will say that doctors may view and edit the complete records of patients with whom they have a care relationship, which makes sense if I'm actually being treated by a doctor, then that doctor should probably see my electronic health record.

On the other hand, if I meet somebody at a party and that person also happens to be a doctor, then that should not give the doctor the right to look up my electronic health records the next day out of curiosity, because here he will not be treating right. Let's look at the next doctors working in the department may view all patient records of that department, but they will not gain access sensitive data. This also makes sense departments in hospitals. They usually have many doctors and others working there.

So doctors working in that same department should have some kind of access, at least a partial access to what has actually been going on in their department. Yet over here, we have a distinction between sensitive data and non-sensitive data.

If you, if you look at the first rule, again, it doesn't mention sensitive data or not. It just says the complete record. So the first one implies that the first case, when a doctor is treating me, they can pretty much see anything. Then there's a third rule. And that is says that doctors may view and edit the complete record of the patient in case of an emergency. That probably also makes sense if I'm lying on a stretch of bleeding unconscious, I think that the doctor treating me should be able to see the information in order to save my life.

So how would we go about if we take this and now translate this into Zima? The first thing that we would do is you would take each sentence, sentence and try to see where are the attributes in there. I've highlighted in red, all of the different places in those sentences where attributes could come into play. So let's start right at the beginning doctors, okay. That's an attribute that describes the subject. We're dealing with doctors. This is all about doctors doing something. Then the next two highlighted words, view and edit. These are again attributes because they describe an action.

Then let's look at the third one, a complete record of a patient that is also an attribute or a set of attributes because it describes the resource that we're dealing with. And then there's something that says they have a care relationship. Now that is also an attribute that, because that describes actually the relation between the doctor, the subject and the patient that owns a particular record. So as you can see, we can identify attributes in all of these sentences and that will then help us model our policies. Let's take a quick look at how we would do something like that.

So if we take the first sentence, this is how I would do it. So doctors may do something now, how do we describe the doctor over here in this subject category, we can use several attributes. And in this case, I think we're going to use a role saying this is a doctor and the doctor probably has some kind of identification, which could be a username, or it could be an identifier in the national healthcare system or, or what have you. So these attributes subscribe the subject, who's actually doing something. It's the doctor, that's doing something. What is the doctor doing, viewing or editing?

Now that would be here in the action category where we'd have an action ID view or edit. What is the doctor viewing, editing the complete record of patients? So that is definitely the resource as the resource ID. I'm saying it's an electronic health record. It has a record ID has a patient ID, and there is a care relationship between the doctor and the pre and the patient. This could probably be put into the environment category. Let's look at the second case. It's similar. The subject category is pretty much the same. We define the doctor as having a role of doctor in a healthcare ID.

The second one says, however, nothing about editing. It just says something about viewing. So in this particular context, the doctor only view. So the action category only has view in there. The resource has similar attributes as before, but now we have something else that actually tells us whether this is a sensitive record or whether a sensitive piece of information in the previous view. It didn't really matter because in that case, the doctor had complete access to all of the record over here, no sensitive information, right?

And we have another environment, category variable, where we can find out whether this is being viewed in the context of a doctor, working for the same department that is treating a patient. The third one is probably even simpler. It just defines the role as a doctor. The action, meaning that the doctor can view or edit the resource is an electronic health record. It doesn't matter whether it's sensitive or not. There's full access here. And in the environment, we have a flag that says, is this an environment? Is this an emergency access? Yes or no.

How do we then take this and model it in Sacramento? I'm summarizing again, the attributes that I'm using over here in those categories. So for the subject, I'm using the role in healthcare ID for the action, I'm using an action ID for the resource. I'm using resource ID, a record ID, a patient ID, and a flag of whether this is actually a sensitive record or not in the environment.

I need to figure out whether this is potentially a car, whether there exists potentially a curation between a doctor and a patient, whether this is a departmental view or whether we're dealing with an emergency access. And this is what the policy actually looks like. Let's go through these things. One by one, the first thing is a target. That's the first white box. Pretty much at the top. The target of a policy defines what this policy actually must match. So over here, I'm saying that the resource ID has to be an electronic health record and this subject must have a role equals doctor.

So if there's any other type of access request, that's not about doctors or not about electronic health records. This policy will not even be evaluated. It will be skipped. So for example, when there's somebody in the billing department, looking up some other information about the patient, that's not this policy that the, that we're dealing with and the decision point would just ignore the policy because it would not, it would not match the policy target. The next thing that we have is combining algorithm.

There are multiple combining algorithms defining Sao AMO, three, introduces several more combining algorithms that are not available. Version two. What they say is how policies and how rules can be combined and how, what kind of results will be returned when you have multiple rules that match. So in this case, over here, we use a combining algorithm called deny, unless permit, meaning that if we don't have any rule over here that permits a particular action. In that case, it will be denied.

There are other combining algorithms that we could use, even though they would perhaps not be so applicable in our specific case right now. Another, just to give you an example, another combining algorithm that we that is available is first match. So the first rule that matches will then be the final result and normal evaluation will be done.

Now, one could be permit unless deny. There are several combining algorithms here, and this will determine how the evaluation actually takes place. Under that. I have three rules that form this policy and they map pretty much or not pretty much. They map exactly to all of my three rules in plain English. So the first rules sent that doctors may view or edit electronic health records of patients with whom they have care relation. In this case, I'm matching an action over here in this rule. And the action says view or edit should be the action ID. So doctors should view or edit.

Now, it doesn't say anything about doctors here and I don't need to, because this is already matched in the target. So as long as, as long as I have it matched here in the target and I'm specifying the role must be a doctor. And the resource ID is an electronic health record. I do not have to repeat the same thing in my rule because this has to apply all the time. So in this particular case, the results shall be permit. Let's look at the next rule. The next rule has as the action ID view. And it says only if the record is not sensitive and only if this is a departmental view.

And in that case, again, we have the results saying the third rule is to break the glass kind of rule that says viewer edit. So if a doctor is trying to viewer edit an electronic health record, and this is an emergency in that case permit, now look at this yellow box next to the third rule. This is an obligation. This is another feature of Zima together. With a result, I can return an obligation. This will be returned to the policy enforcement point.

And the policy enforcement point has to look at this obligation and interpret this obligation and do, as the obligation says, in this case, for example, I could return a permit together with an obligation that, Hey, listen, this is a very, a very unusual type of access, but since it's an emergency, you'll go ahead, but you must log this. You will now have some kind of entry in the system that says that, that you requested to see a particular electronic health record, because there was an emergency and these obligations they can be, they can be used in many circumstances.

They can, they can tell us that a particular action on a particular resource by a particular subject is allowed, but only under a very particular circumstance that must be fulfilled. So now where do all of these attributes live? Because we've had some attributes here that we just magically assumed we would know, for example, is the doctor treating a patient?

Well, how would we know? That's not really for our, you know, for us to write in the policy because we don't know who the doctors are. We don't really know who's treating who, so this is another attribute that we must retrieve as we're evaluating the policy. If we looking in at the Zal architecture, we'll see that a subject, this would be the doctor is trying say to open an electronic health record of a patient. And now there's the enforcement point that intercepts this and says, okay, well, let's see if this is allowed.

First of all, the policy information point will send a request to the policy decision point with several attributes already filled in. So this is a doctor, this is a, an electronic health record somebody's trying to view. And what we don't know is is this doctor actually treating the patient. This needs to be looked up by the policy decision point or even beforehand by the policy enforcement point. In order to do that, the policy information point will be queried to look up that attribute. So the language structure, as we can see is a bit like Russian dolls.

It's, it's hierarchical. What we've done is we've defined a policy with three rules. Policies can be grouped together into policy sets and policy sets can also contain other policy sets so that you can build a dynamic iCal tree of policy. So all in all, don't worry about it. I'm almost finished on this all in all. We have an identity service architecture where we have a loose coupling, but a perfectly well integrated scenario of identity governance of authentication, and of externalized authorization, using information sources that can be anywhere. They can be servers such as active directory.

They can be SQL service, they can be other subsystems, so we can fit information that we will need in order to make policy decisions. So we can go from course to fine grained access control by using exactly the same model of policies. And that concludes my presentation for now and be happy to take questions together with Martin. Thank you very much. So thank you, Felix, for your presentation. And I think it was a very detailed and very interesting over on what really happens.

You, you really translate lets say we were syncing the effect mall and we have a pretty long list questions here. And I'd like to start with some, some of these questions.

So, so maybe let's take this one Phillip, to make all this work, the target application must support exact mall. So can you say a few words on that?

So it's, it's probably a few words on PS. Yes. The target application absolutely has to support SAC. There's several ways to do this. It really depends what your target application is. One of them could be to use an agent, meaning don't even touch the target application, but use some kind of agent or proxies to intercept particular requests and enforce it this way. Another one could be to embed a, an SDK library into your application. That is exactly aware. There's several ways to do this. We have one library as well for Java and for the net that you can take.

And just in a few lines, you can make a policy request at particular, at particular steps in your application for new applications. This is great for applications that you already have. This means that indeed you would have to go back into the code and put this in. So there is some pain involved in getting these types of applications. Exactly more conformant. I hope that just that kind answer the question Martin, you think, I, I think that was, was a, was, was a good answer.

And I think what you will really will observe in the real world is that there are a broad range of approaches to, to create PT and it's even for new applications, there are different ways to do it to from let's say fully exact agnostic to very, exactly aware. It really depends on there are, there's an increasing number. If you look at, for example, axiomatic offers, there's an increasing number of, out of the box PS there. And I'm quite through that. We'll see from all the vendors in the market, an increasing number of, of standard PS, and then hopefully we will list the next step.

Hopefully we'll see a lot more of exact enabled applications of which sort of affect their, their building P P that will be probably the best thing to see of course cloud services. And, and I think that's a, from my perspective, I will say a key requirement for selecting a cloud service should be exactly support even while that would probably limit the number of cloud services. You can select to zero a little bit of last zero, but, but I think that's, that's really one of the point.

So we have a lot of other questions and well, so let's start, just pick the next one, Felix, in, in one, one question, you touched it a little, you you've worked with environment attributes, which seem to hide a lot of complexity and breakfast and that's nothing that interesting point. How is the connection made between the nice Kleenex cycle policy and the messy database query? So the P P IP is one thing, but in reality, I think yes, there might be an issue behind this because if have an nice clean cycle, the data quality provided by the P I P might be not the very best one.

So what is the experience on this? Okay, excellent. Excellent question. But it's actually not one question. It's actually two questions as far as I understand. So one question is, okay, you have a squeaky clean, simple Zana policy. Yet you have all of this information in, in other information points. So you actually doing all the dirty work where the policy information point where the PIP actually is.

And yes, that's absolutely true that that's the whole purpose of, of the thing. The policy should be perfectly auditable. You should be able to give this to an auditor and, you know, even an auditor can kind of look at this and, and look at your high level and say, yeah, this, this matches.

That's pretty much exactly how we said it should be like now, how do you actually look up this, these things, what we see a lot of people doing is they, for example, they define stored procedures and databases, and then they call these stored procedures in order to, to look up whether a doctor is actually treating a patient or not, that that could be in some, some subsystem where they do some web service to find it out. The other question is, well, what about the data quality? So how can you actually judge that your data is, is good enough to make these kind of policies decisions?

Well, I mean, look, if you can't, let me give you an example. If you, you should be able to trust your human resources department in the fact that they should know who's actually employed and who isn't. So if you have a role that says that employees may access the pension calculator, for example, well then that's probably a good policy. That makes a lot of sense. If for that, you need to look up some data on the human resources database to see who's actually employed and who isn't. That also makes a lot of sense.

Now, if you can tell me that if you're gonna tell me that you can't trust your human resources department to tell you who's employed and who isn't well, by all means say you really have a problem and then exactly all isn't gonna help you that problem, because you really need to figure out where you have your authoritative data sets first. Yeah, I think Phillip is, Phillip is helpful. Is the optimistic in trusting that's the data is really current. Yes.

I think, I think the point really is yes, you need sources with the good data quality, but that's not a problem with exact model. It's a problem of all the things behind it. And maybe exact model is something which really helps you to get better there because you can rely on fewer sources than in your current world of authorization. And I think that's another point because you then really can focus on, on having few good sources. And for sure, you can also use some disparate sources if you say, okay, that's a good source for this part. And that's a good source for that part.

It's, it's not one P I P it could be a lot of, I, I think we mean the same thing when you say fewer, okay. Fewer authoritative sources. What I would say is you can go much closer to the actual data source in identity and access management.

Nowadays, we like to build our own silo and say, okay, now we sync everything in this big database. And that's all of the stuff that we copy from the authoritative data sources. And this is now what we use for our identity and access decisions. What you can do is second, what you can have, for example, a decision point much closer to the actual application and have that decision point use the same data that the application is also looking at.

So instead of using a copy of the authoritative data, you will use the authoritative data yourself by, by spreading these decisions, points around, maybe keeping them close to the enforcement points. Yeah, I think there, there, I think we are definitely definitely aligned on this and it's definitely better to not copy about use data, which is still there. Okay. Let's move forward to the next thing.

I, an interesting question I will pick up is, do we need an entitlement server or policies, server, whatever, to implement, accept architecture? The answer is yes and no. No. In the sense of, for sure you can do everything from scratch. Yes. It makes a lot of sense to rely on tools which really support this architecture out of the box, because there are a lot of things like performance in many other aspects, which then are still solved. So I think it definitely makes sense to look at the broader, like the one formatics. Okay.

So we are receiving a large number of questions and we are definitely not able to answer all the questions within the session. So what we definitely will do is we will answer questions afterwards.

I, I will hand them over to Phillip and then we probably will do it in my block as a list of question questions, answer, but we, we have some minutes left around about 10 minutes and I think we will pick some other questions there. A very interesting question, I think is the one we have here, which is about with the number of rules or the number of rules in cases you're supporting pros. How do you address the question of contradicting rules? So you might end up with situations where, where it's very hard to, to manage the rules.

Then I personally, maybe as an end from my side, I think it's a little bit the same situation you're, you're facing in many, an error scenario. If you look at typical firewall environments, you also started with a few rules. You ended up with a lot of rules and some of them might be contradictory, not directly the same, but I think the question of how to manage the contradicting rooms and all these things. That's a very interesting one. Really That's, that's an excellent one.

You actually deal with it in second, the same way that you deal with it in plain old English or plain old German, when you have the requirements in a natural language in English, for example. Well, look, they have to be consistent, is very likely to happen, is that when, if you're the technical person that's going to implement them and you get those requirements and you look at them, you say, Hey, this kind of smells a bit fishy because first you say no. And then you say yes, and, but only this circumstance, but that circumstance can be because of it.

So you have to kind of make sure that they're logically consistent, but if you, if you have exceptions, so, and you use these combining algorithms to say, for example, permit, unless deny or deny unless explicitly permit or first rule overrides or deny overrides. And the other thing is that you can manage nicely by building a hierarchy.

This, for example, you couldn't do with a, with a firewall, with a firewall, you pretty much have one big list of many rules that is being, that's being accessed. Whereas in exactly, you can build a hierarchy and you can build hierarchies that only match particular target, meaning that only apply to specific things. So it's much easier to, to manage. Okay. Great question. Great answer. I would say the next question, I guess high level requirements can be transferred excite policies in many ways in excitement.

So target can be said in rule, or it could be said in policy, are there any best practices for modeling exec policies? Yes, but I can only give you a very short answer because I could talk about this for several hours.

Now, let's say on a very high level, the best thing that you would do is to divide and conquer. So try to split up your whole domain into as many logical parts as you could think about. So in this case, we're dealing with doctors and we're dealing with electronic health records. You could say, of course, well, what's at the, at the core of this, it's maybe not really the doctors, but it's probably the electronic health records because doctors are most likely not the only ones that are going to be accessing these electronic health records.

So in this case, we're looking at something that's resource specific, and we have one policy that deals with doctors. We could have another policy that deals perhaps with, with nurses accessing electronic health records, but the electronic health records would be, let's say the primary part that we're, we're doing over here. So if you build your hierarchy this way, then you can, you you're able to manage it nicely afterwards, but it really depends on on your case.

It could also be like for document management system, you're dealing more with, with perhaps actions and not so much about, about the resources. So it might be more important to divide everything into broad categories of who can view, who can edit, who can create.

So it, it depends on your particular case, but usually dividing and conquering is, is the best way to go here and following your hierarchy. Then again, I track hours about this, sorry, that was So we are, let's say reaching the end of reaching the top of the hour.

As I said, we have a very long outstanding questions. And as I've said before, what we will do is we'll send the request, the list of questions to Felix.

And to me, we will provide the answers and I will put in on my log. And also we put, we'll put a link at the webinar where also find a podcast so that you have access to these answers because we are just, don't have the time to all the question, these questions, and maybe Felix also want to dive in a little deeper into some of these questions where I said, okay, I could talk about hours and maybe adding some links in our things that will be awesome. Very helpful seeing. So for my time, thank you for attending this cooking a cold webinar.

Thank you to Phillip for explaining how to define such policies in a, to really derive them from natural language. Yeah. Thank you. And have a nice day. Thank you very much.