XACML and the Externalization of Authorization: How to do it Right

Good afternoon, ladies and gentlemen, welcome to our call training and externalization of authorization, how to do it. Right. My name is Martin Kuppinger I'm founder and principal Analyst at, and I will guide you through the training and try to transform transport all the messages I have around exactly the externalization authorization, given that it's a very complex topic.

We, we might be able to just to touch some points, but I think there will be a massive information before we start some quick information about could a call, could be a close Analyst company providing enterprise it research advisory services, decisions, support networking for it, professionals through our research services, with all the reports and other things through our advisory services for end users and vendors through our events, including online trainings, webinars, and our equipping call European identity and cloud conference conference will be held next time in May, 2013 in Munich May 14th, two 17th, all the information or a lot of information is available right now.

Other information like the trend level will be published over time. And if you look at our conference website, if also find a lot of information from the UME conferences from the past, including videos of sessions and all these things, okay. So let's directly start some guidelines for the training, your muted central. So you don't have to mute, run, mute yourselves via controlling. These features. We will record the training and the podcast recording will be most likely be available by tomorrow. Questions and answers will be at the end.

So you can ask questions using the questions tool that they're in the go to webinar control panel, which you'll find at the right side of your screen at any time, we will pick them at the end or in some cases, and if appropriate during the draining, but usually at the end. And there's the opportunity to earn CPE points or continue professional education credits. We have to find some learning objectives, which will also find that the website where you find the information about this online training.

So we'll talk about understanding the policy structure define exactly the role of components in there. Especially we talk about strength, shortcomings, first opportunities of using and other types of, or other approaches around externalization of authorization. And quickly also look at some use cases and implementations out there. Event qualifies for one group internet based CPE. If you want to have credit, you will need to take and pass a test. After the training, you will receive a email once your attendance has been confirmed with the link so that you can then directly go to the link.

I also will have some, two or three polls here, the webinar, which to prove your attendance, you should answer in case you try to qualify for the intimate based CPA. So this continuing professional education credit the agenda today, I I've split into seven parts. So why externalization of authorization? First of all, I just wanna set a stage because it's a topic becoming increasingly important. I just wanna wrap up why this topic is increasingly important and increasingly more discussed at many organizations we are working with will then be where comes into play.

Then we talk about a policy structure, components of shortcomings, risks and opportunities, and how to deal with use different types of implementation and then challenges overall dynamic authorization, men, best practices, which is sort of a little bit of wrap up of a lot of things I will be, I will have been talking about during this draining. So like, like in many of my presentations, I started with where high view.

And then if you really look at what happens currently in I heat and there there's three fundamental areas of change from my colleague, Rick bur recently has called it the computing Troy car, which is cloud computing, mobile computing, and social computing. These are the three fundamental changes we are observing and they're leading to what we call it, consumerization and de parameterization of it. So it becoming more ending more and more, at least parting, more and more in the hands of consumers getting more mobile and going beyond the classical parameter of an organization.

And that means we have to, to change some things. And that also affects the way we are doing authorization of deal with authorization, because things are getting more complex if we have not only our mgs, but a lot of our people there, then questions, authorization and, and dynamic policies or dynamic application of policies and authorization decision that are things become more important because the rules and the policies we were following become more complex.

In fact, when we look at the information security overall, then in the middle, the darker area, that's sort of our traditional scope of information security. So looking at internal, it mainly on internal users and some partners, the systems we manage right now, all these three grants of the dry car are really extending this scope. We have to look at and making things more complex, and that's really the area we deal. And that's also the reason from what we see that, that really this topic of dynamic authorization management, which, which is out for quite a while.

So their implementations out for more than 10 years, why is becoming more and more important? And another very important factor within this is what I call the identity explosion. So instead of only looking at some few or some more employees, partners, which are topics for quite a while, still are, are getting access in a, at a larger number, larger scale who are, so there are more partners. And so we have to integrate, especially also that we, the fact that we have to look at our, all our prospects leads and customers. So the numbers of identity we deal with is increasing.

We have to look at a much bigger number of identities. I think it's very obvious that that's trying to deal only with plastic static access management approaches, where we say, okay, we have this access control list becomes increasingly complex with a larger number of identities and types of identities we have to deal with. So also this complexity explodes, and we have to think about new concepts in that area. And then when, when we look at how to address it, it's I think always a good idea to, to sit back and thinking about what is this, what business really wants from it.

The business wants, in fact, two things. They want services, they need to do their job and they want it quick, very quick. And business wants to keep corporate information protected adequately. I think the second part is something which really has changed over the last two or three or four years from security, something it cares about.

And it's not interesting to business towards that's a major concern even of the CEO, because if something goes wrong, the area of information security, you might be the opener in next days, headlines, we, and that only appears somewhere on page 15 in the computer magazine. And so the, a Analyst is much bigger. There's a breach notification, all these things. So things have changed. And that's a real concern of business today. And dealing with information security in a more complex world like I've described at the beginning requires approaches, which are targeted towards this situation.

And so it comes to no surprise that in our core key paradigm, which is sort of our guideline for the future of it, information security plays a very central role. So information governance at the, in the governance side, the information security as the core, one of the two core elements of what we call it, service and security management, which is sort of the central layer of it.

We are, we're seeing where it's about using services, which are reduced different environments to provide what Business really needs. And that's about managing services about securing these things, to provide the services for business, to deliver business services. So this is, I think, very consistent situation we are facing. And that's the question about why do we care or why should we really look at theorization management of things like exac and why is this more important than ever before? I think there are a lot of reasons.

We have the situation of regulatory compliance, more requirements here. We have an increased risk of data loss, like whistle blowing, overall, the concerns around information, security, data theft, and our things as well. If you look at all the Swiss texts, tax information, things happening currently, there are a lot of scenarios there. We have the administrative workload. If you look at an identity explosion on increasing complexity of environments and the cars we have in any environment over time, we need to manage this. We have more use of the identity explosion.

Again, we need to enable our end users to access that request access we have to fulfill our audit and recertification needs.

So access management is really a coing and we've also even been in project where the organization's decided to call a project for access and identity management, because access to cosing they're already thinking about, so also, if you look at the different disciplines within identity management, access management, it's a set of technologies, but there is a little bit more in, in access with respect to authentication as well as to access management and the dynamic access management part at the right side is one of the most important ones here.

So this dynamic access management is cursing to solve. And top of all of this, we have the access governance part for sure, which is then really allowing us to re-certify to analyze to all, to all these things. And then when we drill down within this access management piece, we have this different areas like authentication, like static access management, like dynamic access management and access governance again, and it's about who is allowed to do what.

And within this, the entire area of dynamic access management is what really is, I would say the, the, the future thing, which is really increasing where the awareness is increasing, which becomes more and more important. If you look at it, some pieces are relatively established, like web access management Federation is becoming more and more important privilege management. So looking at all the root users at all, other privileged users is also one of the disciplines, a little bit more familiar.

Then we have two areas which are risk and context based authorization and authentication and dynamic authorization management systems, which are from our perspective, the, the real important things which are changing the first one risk context based authorization and authentication is about making decisions about authentic case and authorizing, authorizing someone based on risk information based on context, information like which device using where at which location you'll see assist the wife secure.

And so on taking a lot of information into account, what was the authentication strengths and so on then deciding on yes or no and dynamic authorization management. That's the entire area where it's about saying, okay, instead of saying Martin, or has access to a specific document, we say under specific conditions, specific rules are met. Them. Access is grounded. So if someone is ly isn't a secure or safe location is part of his organizational unit. And as a matter of factors, he might access the document.

The interesting point is instead of describing it for a lot of people, you could describe one rule and that's then at first dynamically, that's dynamic authorization management. And that's really then where like, I will explain in the next part of this training, where exactly comes into play. So why do we need these systems? One part is externalization. So avoiding hard coded authorization rules and avoiding distributed management of rules. Currently, we are looking at how can we enforce and how can we manage all these authorization rules in some way in different systems.

So how do we set all the active control setting in the active directory on windows, smart servers? How do we manage the things in the SAP systems? How do we manage it here and there and so on? And we have to aesthetically sort of provide things to other systems and all these systems have some security and a lot of rules.

In fact, if you look at reality, especially of customable software, a lot of rules are hard coded in their authorization rules and also business policy. So things like approval level. So which amount of money someone is allowed to do in approval that might change over time frequently, it's hard coded or hard to configure an application. And the idea of dynamic authorization management is to say, okay, let this system ask a central instance about, is this user allowed to do that? And based on the rules defined centrally, this instance says yes or no.

And then the application knows what to do at the applicational level. You don't need to manage the rules. You don't need to distribute information. You don't need to hard code authorization rules or business policies it's handled centrally. The second important thing is you can take factors. You can take context into account. So that's what I've said. You can have a rule, which says not with a mobile device, not, not a specific authentication strength has been been used. So real world or organization rules don't rely on roles or groups. Only.

Currently we we're focusing very much on roles and role concepts and groups, which are important in the future. And they are still one of the most important concepts, but by allowing other factors, other information to be part of such rules, but be part of such decisions become much more flexible. So context is a key environment, especially which go beyond the organizations pyramid. And that's goes back then to what I've said at the beginning.

If you look at this computing drawing, these fundamental changes, then it's also fundamentally important that we are able to define rules, which are flexible enough and broad enough to cover all these changes, which go beyond classical role and group based concept, which we, again, I've said it, and I will come back to this, which we still need. It's also about standardization. So relying on a common set of policies, central place of management and control and audit and more flexible structures for secure collaboration between partners.

When we just simply have to define some few rules for that, instead of managing a lot of facts, controls and other things. And by the way, also we make software development much easier when we externalize security and it's not only authorizations, where are the users stored? How do we handle application? How do we authorize? How do we do auditing? If we externalize all these parts out of applications, then the software development easier.

It's easier because it's just about using a set of defined services instead of trying to reinvent the wheel of security for every single application, which frequently goes wrong. So dynamic ization management is sort of saying, okay, we try map policy to everything. Because at the end of the day, we have one set of information. It's our information we have here in our corporation, wherever it's held on premise or large, but it's our corporate information. We want to protect.

We have one set of policies, in fact, which says, okay, how someone allowed to use that information and the systems besides, so it's one approach to manage access and one approach to go. That's something we can do with dynamic authorization management far better than with any other approach. And so we are, and I've touched exact times before we are the point where exact already comes into blame. So that's where I wanna dive a little bit deeper into this. And then I will step by step gradually, gradually explain exact mode. So I introduce some terms here.

Trial will describe more in detail later, but exec in fact about capabilities in three major areas and there other structuralization I particularly like where we have the policy description and repository. So we describe policies and restorative policies somewhere. There are components. And I will explain the, the abbreviation abbreviations later, which are called P or pap and P P we interface with apps. So applications are interface to those system. They come use exact model for this. There are concepts like PDP and P P in there.

So an application da is able to say, okay, I want to know whether or I allowed to authorize this action. A user has requested or not. Yes or no. And that requires an interface which allows us to use these policies. And then there's an interface with what I would call context providers or information providers, which then provide additional information. Like what is the role of this user?

Some context, information, location, whatever, some other things that could be a lot can be a lot of different, could be a lot of different information, bringing all this together that allows to say, okay, in the current situation, in the current context, this person is based on this policy allowed to do something or not. It's a dynamic approach and exact model is a standard to do this. So it's a standard to describe policies, the standard to exchange policies. So there was a situations where it's more about aesthetically distributing policies instead of accessing a central system at run time.

It's a standard for interfacing with dynamic authorization management system. So the entrance, which are then really doing the authorization decisions at run time, and given that rules can be based in context, we end up as a dynamic set of information. So it's really a dynamic thing which has a defined set of policies, but the results depend on whatever information you request for that specific policy.

So when, when looking at sort of moving towards an ideal world, we have a situation where, where information is used for many services. So we have distributed services cloud and on-prem services, but should still have centralized access policies and base all these things on a loosely coupled approach for us indication the authorization. So instead of trying to have everything centralized and technically provisioned, and so on the idea of a world where we have distributed services, information used by many services, it's more built around.

We centralize the policies, but we try to allow loose coupling of partners of whatever is who is ever successing. These things of external services up to social networks of cloud service and non promise services. And there are several standards like Sam ands, which are standards for authentication, some part of authorization, like as a standard for fine authorization.

And so set of standard system, what really builds sort of a, to, from a security perspective for all these services we are dealing with reality is in fact that we, we have to deal with a world with loosely coupled services with more and more loosely coupled services. So it has fundamental change as first changing. And we have to have a brochures in place which enable us to do this. And that's the reason why a standard like exact is so important. So let's have a deeper look at the policy structure of exact, exact contains of three major areas, which is a reference architecture.

So how does it look like how does this, how do the components look like, how should they look like in an ideal work policy language and the request response protocol, which describes the interaction between in fact, the applications and the central authorization systems and as well between other components within the model. So it's basically, it's, it's not very different from other types standards. It's a standard approach, policy, language, and architecture and the protocol. And when we look at the language structure, then it comes a little bit more clear.

So I start from, from, from the middle, at the end of the day, it's about a decision to make so permit or deny. That's what it's about. And this is based on rules, one or more rules. And these rules can be combined based on a combining algorithms, which defines how to combine different rules, which apply to a specific decision, which is requested. There's a target. And there's an obligation. An obligation is a direct directive from the PDP to the P P and what must be carried out before or after an access. Granted might be, for example, saying, you have to create an audit log entry.

That would be an obligation. And there's a target, which is basically a set of simplified conditions for the subject resource and action that must be met for a policy set or rule to apply to a given algorithm. So rules can be combined to policies. Policies can be combined to policy sets and there we have, and we can combine policy sets to our policy sets.

So it's a, a thing we, we can structure in a, in a, in a hierarchical way, so to speak where we use rules and policies or policy consists of one or more rules and where we can combine policies into policy sets, that's helpful if you have a large number of rules to organize these things. So let's look at a, at a real world example for it's I've, I've took this out of, for Axios presentation, which we, which they did in a joint webinar Axios. And I think it's a pretty good example. It's about access to electronic health records in that case.

So what you see there within there are different rules, like a rule is view or edits a specific relation. And there's a rule which says if an, so there are different types of rules.

If you're, for example, in the emergency environment, you're allowed to use the, the action view or edit. If you're in the environment department view, then it's the thing. And if one of these things is set on permits. So in fact there are three, three rules and, and one is set on permits, then it's allowed, otherwise it's denied. And then one case the last rule, there's an obligation, which says log emergency access. So if it's, if the access is based on emergency situation, it's logged. And I think that's a, it's a pretty, pretty good example for how these, these things look like.

And in fact, it's about is the contract was role doctor allows to access specific electronic health records and their center policy was which consists of different rules. And what happens there in fact is nothing else and saying, okay, we, I have a specific combining combining alleg, and if it's math, then it's okay, and then can be more or less rules in such a policy. It can be more or less complex, but overall it's a, from my perspective, a pretty logical approach to do. And I just wanna also call you on this. So really get your, your feedback on this.

How, how, how you see this type of rules from my perspective, and had a lot of discussions with different parties. I think it's very something which is really logical. It's just really simple, relatively simple to use. And then when looking at this, this rules, so what we really need or to do in exact is define rules, define policies, which ideally should be done by business even while it's in reality, currently done, maybe more by how should I call it more by the, by the brokers or by administrators. That depends more or less on the use case.

So if it's relatively technic, very close to applications, use case, then in many cases, it's more done by the administrators. In other situations it's really more done by, by business users. Ideally it's done by the business users because business knows it's policies best, and it should manage the policies and the basic idea behind these policies. So this person is allowed to access this information under specific conditions from my perspective can be expressed really well in that structure of policies.

So the basic idea behind this is not really rocket science, looking at the XML that might be more rocket science, but if that's really what it's about, then going back to this architecture. So what I've said is we have different components, which do different things. So the pap is policy enforcement point is about enforcing specific decisions. So that's where we connect to the application application asks and then gets an answer.

And based on the answer, it says access granted or not authorized or not the PDP is the decision point, which in fact takes the policies, takes the requests, takes additional information from the policy information point, which might be a directory, which might be a database, which might be different things puts this together and comes back with decision, which as yes or no, that's what the P P then receives.

So PDP has the P IP, which provides sort of the dynamic information about the context of our roles, whatever the P P, which contains the policies, the policy retrieval point, but these policies that are managed as the pap, the policy administration point. So a lot of P whatever piece, but the concept in fact is relatively simple. If you've once got it. So P P asks for decision PDP makes the decision based on information received from two groups of sources. One are they context, information P I P, and what are the policies it's itself P P and it's all managed by another component, the pap.

And interestingly, by the way, if you look at this architecture, if you look at the architecture of common web access management products, then they are pretty much the same. So this concept isn't fundamentally new, it's something which has been taken from taken from established products there. So my view really is that exactly is something which is fairly straightforward from its basic concepts.

I wouldn't say is extremely straightforward if you look at XML, but it's problem of XML itself, not of exact model and, but the idea of describing policies in a relative to simply way, and using them to make authorization decisions, I would say that straightforward to make sense, and for sure to communicate in such an environment standards are helpful. Okay. So that's sort of the basic view on what are, what is the policy structure of XEG and what are the components? What are the components of XEG? I personally think really it's a clear structure or simple to understand structure.

Also, the idea of the components is pretty straightforward. So from that perspective exec, and based on the requirements we have is a very logical thing to do. Nevertheless, there are strengths, but there are also shortcomings risks and opportunities for exact dynamic ization management in general. And that's what I wanted to touch right now. So what are the strengths? One of the strengths is it's the only standard for dynamic association management.

So I, I sometimes have discussions around, we can, could use Sam or OS, which would be a, and a larger, a some know us are no real alternatives because if you transport information, like sometimes it's called claims or attributes for decision we have, which is feasible this first of all, limited in reach. So Sam built on one, I P but if you have information out of it, lot of different sources, then someone comes to its limits where the P I P concept might be the better choice, providing better access, different types of informations. The bigger problem is that policies in the case of sandal.

So one of the leading Federation standards are at the service provider and not centralized. So what does it mean? It means the application requests specific information to make an authorization decision, but the policy itself, the rule set is still in the application and the service provider. So it's still distributed. And then it means you still have to manage policies at a lot of different places. And many of these policies will be hard coded, which is exactly not what we want to do that might be potentially changed by using Sam theorization decision statement query, which is a part of Sam.

However, what is transported via theorization decision decision statement. In fact, the would allow to transport the policy from the identity provider to the service provider. That's not standardized. So the content of this type of query versus Sam is not standardized. The recommendation is to use exec over back ATEC. And so Sam doesn't really solve the problem. And OS on the other hand is too cost grain. So it's also limited. It's more about saying, okay, Twitter is allowed to use some Facebook information, or this application is allowed to use that or whatever.

It's really more on an application to application authorization level, not a fine crane authorization approach. So from that perspective, it's a key strength for exec it's all standard dynamic association management. There's an acceptable level of support by vendors. So several of the vendors, including some specialists like Axios, including a lot of big vendors, like I try to do it in alphabet or CA IBM Oracle quest software to name some of the ones are supporting this concept with their tools. So they are this support by big vendors out there. It's a very logical concept.

I think that's strength. So the way polys are handled is logical and flexible, and also the concept of P P P P and so on. It's pretty logical.

And, and I've said, policies are described in a flexible way and can cover virtually everything from very core screen to verifying grain. They could just say under specific conditions, that one is allowed to access an application. It could be also this approval is only allowed when a lot of different conditions are met. It can be everything. It really depends on your use case. And there's, from my perspective, virtually no limit to describe sort on the other hand, that's the downside of these things. They are also shortcomings.

And I think if you look at the shortcomings, then there are some, oops, sorry, some, some important points there, most vendors currently supporting exactly on their dynamic conversation management systems, these tools commonly are qualities of policy service, or entitlement service don't focus. 100% on exact somatics is sort of an exception because they really focus on sort of 100 person exact most of the others support sometimes currently only two.

They do, which announce per free. Exactly though, but it's not that they are doing everything based on. So there's a lot of more proprietary things in there. And you have to be careful. Then when you look at these products to decide on where do you need the openness and where you, where don't, you need especially important when comes to defining a policy set. And if you want to switch your product at some point of time, it's very helpful if all the policies are described and exact model, because then because it's the standard, then you would be able to exchange these policies with another tool.

So I think that's sort of the thing we already should look at. Can I exchange these policies? Can I have an exact description of this per exchanging it with another product perusing it? So what is the PRP like, is the exact PRP, or is it something proprietary? Another shortcoming is that there's currently virtually cloud environment. So if you look at what cloud large cloud provider support, many of them support Sam today for authentication, but exact is extremely rarely found, which is a problem, especially because there's a lack of such a standards for externalizing policies.

Currently, this means you still have to manage all the policies, all the access controls with the proprietary interface of just SA provider, for example, instead of saying, okay, I use exact app, we're using exact, that's one of the shortcomings, my change over time. However, I think most of the cloud providers trust are not true enough regarding security to really go that step. And probably the pressure from the customers isn't big enough currently to do that. Another shortcoming is that exact model is XML based and XML is complex by design.

So if you look at XML files, if you look at the XML code, sort of, then it's not that easy to read. It's not very hard to understand how XML works, but it's still relatively complex. And it's not what you want to, to show your, your business people and say, okay, you have to describe your policy that way. So it's very important to, to shield XML and to allow people to do their, to work with these tools without even seeing XML for itself. And I that's that's feasible.

And if I look at what vendors are doing, most vendors are really working towards as an for example, trust is an interesting example, like Matics new, so based language alpha, which can be used to programmatically, describe various has been and, and, and, and policies, sorry. Policies has been demonstrated with using 19 line 19 lines of so code to generate 107 lines of XML. So it can be done easier, and exactly is sort of what you need internally, which makes a lot of sense to exchange things, to describe things.

However, I tend to avoid showing people too much of how it really looks like in XML, but as I said, when are making brokers and that, and there's a reason for, for exchange while it's very helpful. And what you also should understand is that externalization for authorization and overall dynamic authorization management is not a, a simple thing. It requires a very careful planning. So we need to understand what, what to do. Who's responsible how to do it.

And so on how to, what does it mean for application or architecture's application implementation and all the things, but on the other hand, and that's what we have to keep in mind exactly itself is pretty straightforward. It's more than looking at real world cases. How do we do it there? And that's something which requires careful planning, architecture, and so on. There are some risks also. So things which might happen, which might challenge exactly one of these risks, that there's no real integration with the increased use of APIs.

So what we call the API economy or open API economy, which is about a fact that that more and more organizations are exposing APIs, which then can be used by others to consume some services, some information from that organization. So especially some of the very big providers, also companies like salesforce.com are massively exposing APIs. And it's for example, interesting to see that Salesforce has more traffic using APIs than using the web based standard in the phase.

So, because it's been about integration of these tools into standard business persons, all these things, and currently authorization that area relies more on OS to row, which is still a extremely new standard. I think it's just through the standardization process. And there has been a lot of discussion around, by the way, we have a, we'll have a, a, a short document talking about, or looking at the discussions around OS two, go out there, I think probably by tomorrow.

So, which might be interesting to you as well. There's a risk of a replacement by and approach based on rest and chase them. So rest restful APIs are a simple way for APIs. Chase is a simple way to provide information back. So it's simple than XML based things. And in several areas, we see that plastical XML based approaches are replaced by rest and trace and based approaches.

However, what we also see is that there's more likeliness that external phases are edited. So we have still exact more underlying, but we can use it based on restful APIs and return or results can be provided in, in chasing. So make things a little bit easier. There will be interesting to observe what's happens. So currently I don't really see that there will be a fundamental replacement, but this discussion might pop up and we will see what happens there. When we look at using this in cloud environments, there's a latency risk.

So if we have a situation on that's a general risk and dynamic authorization management, if all your applications are asking a central instance, which does the authorizations, and they depend on that instance, which means we have a single point of failure, or if we build it correct, maybe we, we have a single point of failure, what we have some high availability to provide there, but the still an issue we're facing. However, it requires a capital planning, this environment and the cloud environment it's even more true because there we have the latency aspect.

So if the glass service is on the other side of the Atlantic, it takes a little time for the packages to pass the Atlantic and come back and problem for us, but it's a problem for machines. So we have to decide on where to place PDPs and PPPs and all these things, which we will have to do anyway. But overall, the, the reality of, of implementation shows that these problems can be solved. One problem we are also seeing is there is an increasing number of proprietary extensions to the standard. So the standard itself doesn't cover everything.

And there are things added like the alpha language by, by, by somatics and other things, and standardization of these things has done slow. So there's some risk of some vendors have their own extensions, which are not really standard, which might make your life easier, but which are proprietary. So you have to carefully look at what does it mean? Is there a sort for risk of a lock in or not? Then the question is what do you really need?

And I think really this dynamic authorization management system, so exactly makes it easier, but dynamic ostracization management works without exact, but if you, if you say, I don't care about exact mold, then there's the risk, a massive risk of login proprietary vendor implementation. So you have to be very careful and, and given that you sort of code your applications in the future and interface your applications with dynamic authorization management system, there's a high dependency of these applications to the system.

And if you end up with a lock in scenario, very hard to solve that issue. So at any time you have to carefully think about what can you do to avoid that lock in, maybe by, for example, using a, your own standard layer between the application and the dynamic authorization management system, which allows you to exchange the backend system without touching the application. That's more about good software architectures, good software design. I will touch it later again. And as I've said, risk is no one wants to deal with exactly directly.

So it's becoming increasingly transparent for developers, etcetera vendors are making good broker here. However that given that interoperability use cases still are relatively rare. There's a little bit of question for the practical need of exec. I still believe that it's better to have exec in the background because it allows you to interpret. It allows you to exchange things. It allows you to integrate different dynamic authorization management systems you might have in a larger organization. So it allows for a lot of things, but it's still not a common scenario to do that.

Hopefully we will see it and there's, then there's a big value. Then it's also sort of an opportunity for exec one. There are some other opportunities, one of the big opportunities that the need for externalization of security is better Analyst than ever. So I see an increasing number of organizations which are thinking about it and an increasing pressure from, from new use cases, the ones I've mentioned at the beginning, a lot of others, there's a lack of a real alternative, and that's an opportunity forec cause there is no standard available which could replace exec.

And given that exact is relatively big standard, it will also be not that easy to, to, to define another standard for that area. We also see that vendors of exactly that space of dynamic authorization management are pretty innovative. They're supporting more application to more things, try to add, to, to fix some of the, the, the issues with some types of complex queries and other things. So it's very interesting to see what happens here and there, as I've said several times before, they're making brokers and simplifying the use OFAC, and finally they are more and more out of the box.

So these policy enforcement points, which the interface between your applications standard applications are cost applications like SharePoint and whatever, and custom built applications. There's an increasing number of ways to interface it with the dynamic oration management systems, which makes it easier to deploy that of solutions. So what are these types of solutions we're observing out there? I've just picked some, some few examples.

There, there are a lot more out there, but I try to pick a lot of examples from very different environments, very different use cases. And so one of this is for example, that one use case might be extending your mainframe or organization to the client server world.

So in a situation where you have historically seen your mainframe based on, on central authorization management system, which is not uncommon common in, in, in mainframe environment, it might be about saying, okay, I want to extend it to support all of my new J applications, new other types of applications, my top net applications, whatever. And then the traditional mainframe custom built P authorization management systems are not sufficient anymore.

And that's where, where it makes a lot of sense to convert all this into exact mode, maybe use the existing mainframe, mainframe authorization system as some system, which then use the policy managed centrally at least that part, which is relevant for the mainframe. We once helped the customer to define an architecture and that. So that's one of these use cases, another use case standardized standardizing application security of a software vendor, and a common framework.

If you look at what Oracle is doing with their OES or Oracle entitlement server there dynamic authorization management system, they are basing more and more of their application security of business applications like their, their Oracle applications and others and all that type of stuff, but also database security on that concept. So it's an approach where they say, okay, customers are, are easier able to handle all the different security requirements of different applications than building on a consistent set of policies and building on a consistent concept. That makes a lot of sense.

So instead for software vendors having or following that approach allows to implement a consistent approach and security across all of their software products, another example, payment authorization, PayPal. One of the biggest examples for, for use of exac where it's about a lot of relatively simple decisions, but an extreme big number of decisions made support for complex context and risk based authorizations based on increasing number of factors and open parameterized parameterized ized environments.

That's what I've been talking about at the beginning, when looking at is computing casting, that's really where you need it because you have more complex rules for decisions. And our example is compliant access to documents in regulated industries like defense, aerospace, healthcare based in policies, define your policies and say, okay, which are the policies to allow access to documents.

And then you have a central set of policies, which is enforced it's much easier to direct compliance, ensure compliance to fulfill audit requirements than by managing X controls, you know, big number of disparate systems. And it's also much easier to add new groups of users by just adding a policy, standardized policy management and financial institutions. So financial institutions are a pretty good example for organizations which have pulled on dynamic organization management systems for quite a while, in many environments, especially in the mainframe environment.

So there are a lot of use cases out there for many, many years. And for sure, it's very logical to do that on exactly these days, but the integrity of customer information data is another example.

So there, there are really a lot of different use cases from ranging from classical eCommerce or payment things to document security, to security and financial and institutions and so on. And if you look at reality, I think it makes a lot of sense to go to the path, to look for dynamic authorization management. So with the strength, shortcomings risk and opportunities, I've touched some of the challenges, some of the best practices. I will have a look at some other points right now as well. And some other things you should keep in mind.

So one of the most important things, even while I've talked a lot about technology at the end of the day, it's going well beyond tools. It's mainly about method methodology. So we need to understand guiding principles, implementation guidelines, core requirements. We need to understand basic concepts like how our, our access management processes ertification auditing for this entire world policy description. How do we deal with this? And so on to detail, this concepts to look at how does it work with different types of applications? How do we deal there with all these things?

And we need the processes in organizational structures. And if you don't build at that framework, this will fail. It's not a technical thing. You might use it. Technically, maybe if you have a specific application where you think it's better to use some dynamic oration management system, but if you want to roll it out on a larger scale as a standard security concept, then it's very much about process organization and about things like procurement guidelines and other things. When looking at governance, again, all these types of apps rely on authorization rules, some of them overlap.

And with exactly we can standardize the way policies are described. We can have one policy, which is the use different systems, very different types of systems. You can manage policies consistently, and we can audit policies consistently. And that's really where it's made for heterogeneous distributed environments, because it makes us governance much easier built on policies. Exactly that is really moving towards the standard authorization environment. We have business policies which translate into excite. We have audit trades, which are based INEC.

We have context information, which then is requested and provided to the application. We can really create a standard environment, which is independent of the different applications. We still will need an approach for access governance, by the way, which is going beyond access governance. And several pieces of access governance are available today on a broad K like warehouse warehouses and analytics re-certification adaptation or role management. Others are sometimes found like access to request management, risk management.

What we currently like there is this support for dynamic authorization management, but tomorrow we will need it. We need one approach for all types of access, which is built on one set of processes. Recertification approach is providing rules, which are an important part of the entire concept of excite and productization management, which allows us to deal those rules of broad range of attribute use, and decisions, and do an auditing there due in a consistent way. So that will be one of the other challenges we are seeing the first, some, maybe two vendors.

We just started to, to look at this and try to implement it, but it still will take some time until we have a broad scale. I think another interesting point is you might have a, a look at a draining we recently did on the enterprise role management, which, which is available as a, a recording podcast right now, where we explained our overall concept for dealing with roles, deriving roles from organization, from contracts, from functional innocent processes, and where end up with business roles, which then maps down to entitlements. So this is a, a pretty complex picture.

And if we, if we do it based on dynamic authorization management, a lot of things become much easier because based on the functional roles we have, which are derived from our process description, based on the constraints, which also into the context information, we can then derive everything down there. The business role, it role entitlement saying, we can sort of avoid it saying that's described in this dynamically, but that requires some dynamic authorization management, which would make our life in that area much easier. So we don't need it. Role system level entitlements anymore.

It systems director support the concept. So things become much easier in that case. And as I said, it's, I think very worse to have a, to, to listen to the recording of the enterprise role management podcast, with respect to this topic I due to the, the time I trust can touch it very quickly, but it's very worse to look at.

So technologies have to change also from that perspective because static access management is a common approach, requires a lot of mapping, a lot of work around business roles and lower level system access controls, dynamic authorization management makes it easier because we do it at runtime. We build a, on a relatively simple, straightforward set of policies, which is far simpler management and implementation, but we have to move forward. And for sure it will take a long time to sort of migrate our legacy applications.

So as a recommendation, you really should think about layers and reference. So, so layered architectures where you say, okay, avoid dependencies on when specific components become flexible for standard changes. Those should be standard changes, simplify live for your developers, administrators, and business uses. So hide a little bit of exactly, especially hide when specific implementation details and remain flexible.

There are some approaches like simple business integrated admin interfaces, policy auditing done based on something which isn't exactly, which is just really looking at a business like description of policies and pap is reducing the complexity in hiding cycle details. So my ideal is that I write one line of codes that I involve one method where I say, okay, that's what I want to have. Is this authorized or not? And then return value. It's not about saying I understand exactly what I code and application. So that's a very important thing to do there.

So how to move forward, finally understand the concept of externalization scope, what and where to externalize, where to start, where to move, define a strategy, understand what is your, really your strategy, your approach in doing that define an architecture. So how does your future authorization framer should look like define organization processes, create a backend and then start externalizing authorization. That's it from my side. So we can probably take some one or two questions. If you have, you can answer these questions, using the questions, tools, and go to webinar.

And then I will ask discussions. So I have another quick poll in the meantime, if you like to answer it. And as I said, you can then enter your questions. That will be more call trainings and webinars within the next few weeks. So there's a series of things happening within the next few weeks, and you should have a look at our website and the what is happening there. There will be also some, some interesting reports out there. There's some new out there, like the future of indication, which also touches a little bit, the future of authorization. There.

Some other things like as mentioned the short piece and was another one on the recent one. Well, their ability has been detected and some other things. Okay. So if you have questions, enter them now, or you also can drop me an email. If there are no questions, then it's up to me to thank you for participating in this call webinar. And what I just can recommend is start building your concepts for externalization of security out of your applications and for dynamic authorization management. And for sure don't miss to visit next year's European and team cloud conference.

Thank you for attending this call online training. Hope to have you back soon. One of the other trainings. Thank you. Goodbye.