Well, good afternoon, ladies and gentlemen, welcome to this webinar from static roles to dynamic attribute based authorization, authorized flexibly, make decisions in real time, ensure compliance. This webinar is supported by axiomatic. Your speakers today are my name is Matthias rebar. I am senior Analyst at Ko, a Cole, and I will be presenting the first part of this webinar. And in the second part, Jerry Gable, president of axiomatic Americas will take over before we start some housekeeping. And of course, some general information about cooking. A coal as an Analyst company, Cola is providing enterprise it research advisory services, decision support, and networking for it. Professionals. We do this through our research services where we provide several types of documents, including our leadership documents, comparing market segments, advisory notes, looking at various topics, vendor reports, executive use, et cetera. We do this through our advisory services where we provide advisory to end user organizations and vendors.
And we do this through our events like webinars or seminars. Our main event is the EIC, the European identity cloud conference. The next DIC will be held in Munich from the 10th to the 13th of May, 2016. And we think it will again be a must attempt event with a large number of speakers and sessions in the areas of identity and access cloud and digital risk. Next month, there will be an interesting German language, unfortunately event one day event, and we spar, which will be focusing on the transition from traditional cybersecurity towards the next generation cybersecurity in the world of the digital transformation. And please consider having a look at our full event agenda for all upcoming events, using the given URL on this slide, some guidelines for this webinar, you are muted centrally, so you don't have to take care of this. We are recording this webinar and the pop and the recording of this will be online at the slide dates tomorrow.
Latest on our website, there will be a Q and a session at the end of the webinar. And you can enter your question during the presentations at any time using the questions or starting button, depending on the language version of your software on the right side of the go to webinar software, please do so so that we can start the Q and a session right away with a good set of your questions. I encourage you to do that, to have a good Q and a session our agenda for today, the agenda consists of three parts. The first part will be my view and introduction into the need for dynamic fine grained access rights in a modern enterprise. The second part will be presented by Jerry Gol, the concepts and implementation of a policy server infrastructure as an exemplary dynamic authorization system. As the third part, as already mentioned will be the session. So let's start right away with our first slide. And with my part, all parts will be some 20 minutes long so that we get to almost an hour in the end. So let's start.
We are talking about access decisions when we're talking about authorization and access decisions are currently executed in a changing world within the digital transformation and in a challenging world, we have to answer a simple question actually, who will have which functional access to what, and this should be an easy question to answer, but it isn't. We will always get to something like yes and no, but we have really complex environments. We have many identities, we have many access locations. We have people accessing the information from various sites from home, from their, from their desk at office. And somewhere in between from the mobile phone, we have many service locations. Services are located in many places on premises, in the organization, in the cloud. For example, we have many devices and many, many different types of devices, some secure, some less secure. We have many functional requirements in the changing world of, of, of business processes and new business models.
We have functional restrictions for various reason, technical or legal restrictions or regulatory restrictions. And we have of course, concurrency and the dependency. And we have to make sure that parallel operations are segregated from each other in an appropriate way. And of course, one important point. And I think Jerry will have to look at this as well, is audit, logging, and compliance. It has to make sure that every access decision that has been made is, is correct, of course, is well documented and has appropriate evidence for the actual decision. If we go back to the traditional rback role based access control role management process, this is something, a slide that most of you have already seen before. It is the way that roles are modeled. There is something like a job function, which is defined by people like enterprise architecture or human resources. They define job functions, and then some people derive business roles, for example, the lines of business.
And they do this in a top down approach up to a certain level. And on the other hand side, we have the entitlements, the technical aspect of role management. We have it systems with entitlements built into them. We have some technical roles which bundle individual entitlements within an application. And this is the bottom up approach. And this is usually done by the it people or the, the system owner, the application owner, or a process owner. And the important part usually is designing this what happens on this dividing line between these two parts and this role engineering and this job, this, this job position is actually one of the toughest within an organization because these people have to match the technical roles with the business roles and have to assign the right technical roles to the business roles. And this is the usual way that it's done and many organizations are doing it that way.
And they come to a working set more or less working set of roles that they use for authorization. And for assigning people with the required profiles and roles might represent different types of roles of, of semantics. At that point, it could be that a role represents the association to, to an organizational unit. For example, one is in sales, an employee it's in sales. It might represent on top of that or in parallel a job position. It might be something that NTS a person within the organization and within the organizational unit, it could be something like a base role. Somebody enters the organization and he just gives, gets the role employee. And this is a base role which allows him to access Microsoft office or outlook or log into the active directory. It could be that a role might represent additional functionalities, like competencies, a senior role.
And we always also save senior role. It adds additional functionalities competencies, and it could be something like just an attribute. It could be a role that tells an application or the system that somebody is an external, it's not an employee of the organization. And it could be something like non organizational competencies, something like an administrator or an audit guy or, or lady who has to make sure that he has the right access to, to control, to, to have, to, to look into audit locks, for example. And there are many other possibilities. And I think all of us who have joined today know that there are other possibilities and much more, more or less appropriate because once you have designed a role model, you tend to, to put everything regarding authorization information into roles, but with changing requirements and changing enterprise structures, this is yeah. Slightly changing currently.
And I'm just going through these aspects quite quickly, because you know, all of this, we have this so-called digital transformation. We have people getting our organizations, getting new business models, getting out into the internet, into the digital world, providing services and products there as well. We have the connected enterprise. We are talking to much more people than we did before than we did before. For example, we talked to our supply channel to our people who consume directly from us. We have changing supply chains, which, which requires different types of com communication and different type of identities and their access and authorization. At that point, we have changing business processes much more direct, much more in touch with the individual customers. We have globalized markets. We have the moving security perimeter, which means that actually the traditional firewall infrastructure hiding the organization behind walls is actually in many places, no longer off existence because the actual security perimeter is yeah, the application, the identity, we have mobile access of various kinds. We have the internal people, the employees, we have external people using iPads, mobile phones using the traditional laptops. We have the custom customers who access our systems probably with their mobile phones and authorized authenticated via their social media platform, Facebook or Twitter. And of course, we have this large area of bring your own device with people saying, Hey, I have everything I need. Just give me access. Just authorized me.
We have new types of infrastructures. We have cloud infrastructure and we have software defined infrastructure. And this means that many new infrastructure components need authorization and authentication services. And as well, we have daily growing security requirements and re regulatory requirements. That means that we have to make sure that everything we do within our business is actually covered appropriately. And we have to make sure that we can PR provide evidence for the, the compliance and for governance. And an interesting point as well is the secure sharing of intellectual property. We want to make sure that our supplier for example, gets the right C a D drawing that he needs to provide part for us, but this has to be protected appropriately. So once we have looked at this, we might realize that we have much more to look at than just roles. A role might be a good starting point, but a role might be enough, might not be enough when you look at additional attributes that might come up in every building block of a transaction.
And this means this simple question from the beginning, who has, which access to what might be influenced by various parameters. And this could be something like who is doing it. This is something we do know. What is the data that the persons want want to, to, to access? What is the actual operation in detail that he wants to execute, or he or she, what is the accessing device? Is it a security device within our company, the desktop computer within a secure environment, or is it something that is in a rather insecure environment, public network, and it's a, a shared device or it's a, a mobile device. And we have to know which service provides the actual functionality that we need. And we have much more when, when it looks, when we look at the actual building blocks of the transaction and we have something that is, is new as well for us, we have to look at at context, when does something happen?
Because, because even employee starts to accessing the information at three at 3:00 AM in the morning, that might be right, but it could be the chance that it's not a legitimate access at that time. And if he does it from a country where the organization actually has no office, and he's not on vacation, then this might be an issue as well. And the network from where, or he, or she comes, might be an, an interesting attribute and historic information might be of interest as well. If this access is usually something that has to happen only once or twice a month, and this full backup, for example, is executed the, the 10th time within five minutes, this might be an issue. And so this historic information might be interesting as well. And there are lots and lots of more attributes or parameters, which ha we have to look at apart from the traditional role modeling requirements for today's authorization.
This is also something that most of us really know, but something is actually changing. And it's, it's basically focusing on agility on speed on, on, on versatility. So of course we have to have flexible authorization mechanisms, and this is something that Jerry will look at in more detail later in the second part, it will be dynamic so that it means that we can change actually the, the authorization process at run time, if required, it has to be fine grained, potentially much more fine grained than we used to have it with the roles that I've described earlier. We need to have fast results. It still has to be fast, even if it's dynamic and fine grained and flexible, we have to have precise results. So these are the real results that we need for, for basing a, a good authorization decision upon this. We have to have the immediate implementation of corporate rules.
So that means if corporate rules change, then we have to make sure that we don't have to get into a long term role modeling process, but rather change the decision process appropriately. So that means that the roles rules that has to be easily adjustable. And in ideal case that we have it centralized externalized in a central point, at least in a scalable infrastructure that makes sure that we have the decision infrastructure at one point, not within every application contact spec specific, as I told before, this is something that is a requirement for today's authorization. Of course, we have to be sure to the regulatory requirements that we have at the moment, and this will change soon. It must be auditable so that every auditor can actually ask for, for evidence, which decision has been, has been made and executed on, on which basis on which rule on which rule set.
And of course, this has to be at an appropriate scale. We are not no, no longer talking about accounts, 10, 15,000 accounts, but we are talking about internet scale. We are talking about yeah. Infrastructures that have to be potentially in the, in the situation to handle large scale volumes of, of requests. And of course this must be still well integrated into your organization and into your business model. So these are requirements that most of us encounter every day, but it's changing at least in velocity and in volume. So one central point that we will have to look at, as we said in this is a policy based approach. We have to understand what policies are. So I looked into the missed special publication, 801 62. The link is below to the right, and there, you can pick up this document and actually policies are simple construct, which govern allowable behavior.
So they define, they govern allowable behavior within an organization or probably beyond, but at least within an organization, we have policies that, that, that act based on the privileges of subjects, which is the first dimension we policies act on the basis, how objects are to be protected. So this is the, the second dimension subject versus objects. So people acting and what is to be accessed data functionality and under which environment conditions. And this is something that we will see later on in when, when Jerry tells us about how this actually is put into, into existence into a, into a real life system.
So if you look at authorization within organizations today, we will find something that we call the AAC continuum. We have the role based access control that we have before. And we have AAC attributes attribute based access control, and usually authorization processes will take place within the, the spectrum of pure role based access. For example, a base role is a base role. There shouldn't be much changes to that, but there might be authorization decisions which might need much more fine grained basis to, to, to act upon. So we have roles to the left, which is the, the pure approach we add constraints. And we add the organizational structure, which adds actually new, new dimensions of, of, of information. We have typical business activities, which restrict or define the actual authorization request. We have context, as we said before, and risk is an interesting point. Of course, we have to identify which operation is actually more sensitive than another, which bears a higher risk, and which should be considered with more sensitivity when it comes to assigning access.
And we have lots of other attributes that, that we've seen before. That means that we have this continuum between purely our back and perfectly AAC and today's authorization systems will have to make sure that they cover everything between the two extremes and yeah. And all on both extremes as well. So if you look at the actual process, I think that many organizations currently are in a position that they do have a role in place, at least basic profiles that they use and adding dynamic authorization means actually some changes to many components within organizations. And the first thing that we need is we need policies. The, the usual role-based access typically does not require policies. So we do need it. That means adding dynamic authorization to a role-based authorization means we have to define enterprise policies. We have, which are usually not actionable. These are the basic enterprise policies.
We have to derive actionable access policies that actually can be put into a system and actually decide something, do authorization. And we have to implement them. We have to make sure that access decisions in the best case are externalized put into a central system, which does the access decisions for all consuming applications, infrastructure, systems, and services. So this means we need to change architectures, we to change code, you have to have somebody doing that. We have to implement this authorization infrastructure. It has to be there. So it's a per new infrastructure based on existing of course. And very important aspect is we have to make sure that we maintain an adequate data quality. At the moment, we are basing access decisions on attributes. We have to make sure that attributes actually are correct, complete, accurate. This is actually a real important thing because dynamic means attribute based.
Of course, we have to maintain compliance. We hopefully did it before when we used our role-based approach. And when we add dynamic authorization, we of course have to make sure that we have compliance in place as well. So effective governance must be in place and maintained and evidence for policy conforming access decision has to be provided as we did before. So this means adding dynamic author dynamic of our dynamic authorization means we have to provide integration strategies into existing infrastructures and transition strategies. And if we look at the types of people and the departments we have to talk to, you see that there are many we have to talk to, we have to talk to software architecture, which has to implement this into their architecture model. Developers must be enabled to actually do this. It security will have to make sure that policies are in place, correct.
And, and, and continuously adjusted when required. This is also something that enterprise security has to has to understand, has to lay the foundation layer for that audit has to understand that there is new systems to look at compliance and governance is something that has to be appropriately amended to allow for that business has to understand that we are now in the position that authorization can be based on the, on attributes with, and we no longer have to are no longer forced to think in roles. Only the it architecture, the infrastructure architecture has to know that. And finally, it operations also has to make sure that they understand what has changed and what is required. And at that point, I would like to hand over to Jerry Gable and would like to, to ask you as the participants to enter your questions and so that we can start off immediately with a Q and a after Jerry's part. So Jerry,
Well, thanks very much for, for that introduction in that presentation. I think that establishes a great baseline or foundation for some of my comments here and, and further context. I'd also like to say that this is always an interesting discussion that we have at the European identity conference. And I remember that from this year's session as well, there was some very good panel discussions and a lot of good hallway conversations about this topic. I think it's one of, of great interest to people. And furthermore, I really appreciate keeping your Kohl's research on this topic area. I really like the, the analysis and, and the content that, that your team provides. So thanks very much for that.
Now, in a lot of organizations, we do have security architects or enterprise architects that think they should be moving toward an aback model. You know, this is something that's been discussed for several years now. And as Matthias has pointed out, you know, there are a lot of, you know, a lot of organizational or, or business requirements that are making people consider this mode of operation. But of course our back is the predominant way that we do access control today, either with roles or with group lists that act like that act like roles, but the, the question always comes up, well, how do we get there from here? You know, if I've been using roles for all of these years, how do I start looking at that dynamic and attribute based access control model? Now for this presentation, I, I decided I would like to start with the end or start with some conclusions and then try to, you know, support those, those arguments or those conclusions.
The first one is that you've been thinking about roles or group based models for decades. You know, those of us that have been in the industry for quite some time, certainly can, can relate to this. And this is a, a significant obstacle. It's a non-technical obstacle when you think about moving toward a dynamic and attribute based model. So I, I like to say this is a, you know, a subtle but very significant thing to consider. So I hope to talk more about this in a, in a few moments next step externalization of the authorization or the access control is really a key characteristic here. Matthias touched on this a few times, and I'd like to point out that we, we, you know, it's desirable to externalize the access control logic, whether it's simple and role based, or if it's more complex than dynamic and attribute driven. And there are many reasons for this, you know, the ability to change the access control rules faster, you know, the ability to audit the environment more thoroughly, to provide more transparency into what's happening within access control. So even for simple or role-based models, we think it's important to externalize that function from your business applications.
Next step, I'd like to suggest that a, a policies actually more closely represent your business and security role requirements than a role or group structure would with their associated permission sets and profiles and so on. And this really hit me one time when talking to some security architects at a bank, we were in a meeting and, you know, discussing roles and AAC and, you know, the different kinds of requirements they're seeing. And the, the security architect. One of them said to me that, you know, when they go to talk to the business people, and this was a banking environment, you know, they go to the, you know, retail bank management and they say, what kind of roles do you need? And what kind of permissions should we create? And the bankers kind of look back at them at blank stares. And they really hit me well, well, of course they would because they don't talk in that kind of language.
They think about, well, tellers process deposits or mortgage lenders, analyze mortgage application forms. And, and the like, you know, these are the, the way business people work and it's, it's contributes to the difficulty of us. It, people to talk to business people when we talk about roles and permissions, rather than something that's more in a natural language format. And we've got an example of that coming up, our back practices result in it constructs. And, and this gets into the discussion of entitlement management versus, you know, attributes based access control. So these it constructs, you know, these roles, these permissions, these entitlements are what, you know, it typically creates to try to bridge this mapping between the business rules and the machine language requirements. And so we use this in entitlement management and we use this in user provisioning practices, and we could probably, you know, do a deep dive and do a whole webinar just on, on this topic by itself.
But in contrast, I'd like to say that aback policies incorporate business metadata, therefore actually reducing the need for this, this entitlement management. And what I mean by business metadata is the, you know, the data that your business applications use when it's dealing with customers, you know, maybe it's customer region or customer balance or invoice status, or some status of some other kind of record, you know, purchase order. Is it approved? Is it in review or some kind of transaction state, you know, is it pending? Is it, you know, it's somewhere in, in the middle of its process or has it completed? These are things that, you know, for example, provisioning systems don't have visibility to and don't control, but your, your business applications use them. Currently.
Another point I'd like to, to make here is that we suggest you do not attempt to directly map your current role definitions into aback policies. We, we think you need to slightly reorient yourself before doing this, and I'll touch on this at the end of the presentation. But what you want to avoid doing is ending up with as many policies as you do have roles currently. And we've certainly seen some examples where you can run into that kind of situation, is that certainly not optimal or the most efficient way to go. And the last one of my conclusions here to start off with is that you still need roles in an AVAC system. So we're not talking about throwing out everything you've invested in over the, you last several years, we're not talking about throwing out those, those role definitions, rather as Matthias pointed out, adding to that, you know, adding additional context, adding additional attributes to those roles.
Because in fact, we, we consider roles to be a first class attribute. You know, most aback policies are based on roles that is, you know, manager can do this. Employee can do that. Contractors can do something else. So role is very, very important. MITs also pointed out the continuum that is you will have a rich mix or a spectrum of different kinds of applications. You know, those that are fairly basic and just need to, to determine access based on a role or group membership. And those that are very complex that need to consider time of day that the type of device is it managed by the organization. If it's a, B Y O D device, is it registered in our mobile management system and so on? So you'll have this fairly sophisticated continuum to deal with here. It's not going to be only attribute based.
Okay. So let's move into some supporting arguments. See if I made the case properly here. And the, the first one I wanna make is, you know, know, contrasting external authorization versus internal or legacy kind of authorization. And certainly you're aware of this, that whether you buy a commercial off the shelf application, or if you have in-house development, you know, that, you know, most many or most of your applications have this kind of logic already built into the application. So you've got a mix of business logic and security logic in, in your application. And this is part of the, you know, this challenge of auditors, right? And people trying to do access governance is to determine what, what is the, what is really happening in the application? You know, can I really address all of my audits and, and compliance concerns? And then also if I need to change these rules, then you know that I need to change the source code of the application and go through that kind of process to, to make a rule change.
If, if a regulation or some other privacy role, for example, changes in the future now to externalize authorization. There's a, there's a basic architecture that we follow here. You know, you have some user trying to access some application. And the first component of an AAC or dynamic authorization system is some module that stops that flow, whether it's, you know, different parts of the application architecture, and it sends off a request to this external authorization service. And this is where the, the policies are defined and managed centrally, of course, there's different deployment models that can be distributed or even embedded within your application. But the notion is that you have a central service where the policies are defined and we're talking all about attributes. So potentially we need, may need to connect to attribute sources. And that's how we do it here. I've got another slide on, on this particular aspect in, in the near future. And then this, this authorization service makes the decision based on these policies and all the attribute data made available. And it will return a permit or denied decision to the application, which you, you know, if it's permitted, obviously the flow continues. If it's denied, then the user will see some kind of error message. So this is the basic architecture for an author, an external and attribute based authorization service.
Now, a few comments about policy modeling and the Matthias pointed out that this is an important aspect of dynamic and attribute based system is, you know, we've used roles in the past, but now we've, we're introducing other attributes. Well, what ties the roles and attributes together? It's the policy language behind an aback system. That's a really important concept that sometimes is, is missed. It's, there's really a policy language here that takes a natural language kind of statement. You know, brokers can view insurance policies of a customer if the broker is assigned to the customer. And what you essentially do is you break this down into the different attributes and you can see the first one was a role. So again, roles are very, very important. We have an action verb here, view the resource of course, is the insurance policy. And then what's key here in, in the, the purple is that the policy language can represent the relationship.
That is, it can compare the user ID of the requester to the, the, the, you know, the customer record itself and see who is assigned, who is the assigned broker. And that's, that's a very powerful concept in an aback system, being able to represent these kinds of relationships. And at the bottom is sort of a broken down view of this. And this is essentially what ends up getting translated into the machine, readable language that the policy language, and, and certainly we, we provide different kinds of tools for different skill to create these policies, but you can also use third party tools that do near natural language processing to create the machine readable aback policies. And the question that often comes up, and maybe we can touch on this later Matthias, is that, you know, who, who does this policy authoring? Well, typically a mix of people, probably the same kind of people that, you know, the role engineers are already talking to that is the business owner's information security audit, you know, to make sure that all, all the angles are are covered and that the policies are properly structured.
Now briefly, just a moment, you know, a note here about entitlement management. Again, we often see, you know, checklists or different kinds of spreadsheets or matrices or permission sets that, that it creates and manages. And we think you need to do less of this. And then more of the previous, you know, more of focusing on the, the policy modeling and the attributes used in the policies rather than, you know, permission sets and entitlements and so on. And also I mentioned earlier how aback policies use business metadata, and I give some different kinds of examples here. And in fact, your business applications already use this data. It's probably in all of that, if then else logic that I, that I pointed out earlier, but you can see here also that it opens up a whole new range of data elements that you can use in your policies, but also to Matthias point, you have to ensure that there's proper care and feeding of this, of this data, because if it's used and now in an access policy, then we have to ensure that the data is accurate current and so on.
So the next section here is about implementing attribute based access control. And how do we go about doing this? And I like to characterize it as three major categories of activity. You know, one is the policy creation. Second is dealing with the attributes and the data model, and then the third being the integration with applications. And I set aside for the moment, things like deploying the authorization infrastructure for high availability and, and, and performance and scale. And so on. I set that aside for the moment now, as far as the access policies, we, we did just touch on that a couple of slides ago. And so I won't go into that any farther only to, to, you know, again, reinforce the fact that we, we start that process more from a perspective of natural language statements, rather than trying to calculate, you know, roles and, and permission sets and, and, and things of that nature.
But in the next slide here, we'll start to talk about attributes themselves and for an authorization service, you need to think about where do the attributes come from. And essentially it's from two different places. One is they could be included in their request message in the basic architecture example. It says something like Bob is trying to access at some particular record number. So we know that, you know, Bob is the subject he's trying to view a record and we know the record number. Okay, that's the, you know, a few attributes, you know, typically from the authentication session, but for re you know, resolving the policy, I may need to look up additional attributes. And at runtime, we mentioned that the authorization service can connect out to different kinds of attribute sources. In this particular graphic. I show the use of a virtual directory, the VDS service in the middle here that can actually aggregate and consolidate many different data sources, or you can use the author authorization service itself to directly connect to these different services. And they can they're typically directories or databases, but they could also be a web service JSON service, even that Excel spreadsheet or a comment separated file. So lots, it can take lots of different formats, but this is an, is an aspect of mapping, the attributes you use in your policies to their, to their source. So that is part of the, the implementation exercise.
And just a, a few comments here about where you integrate the authorization service, and you see some acronyms here, policy enforcement point or P P the policy decision point or P D P. These are typical acronyms for, for an apex system. What we're trying to point out here is that you can, in fact, put your enforcement point or your interception or integration code at different places within a typical application structure. And you may do this in just one of these places, or you may do this in a combination, and it depends on what kinds of rules you're trying to enforce within the application.
For example, if you're doing it at the presentation tier, you may want to control menu items, dropdown lists, you know, activate or deactivate buttons. And you can do this in a variety of programming languages. You know, historically it's mostly been done in javan.net, and you might choose to use a vendors S STK for this, particularly if you follow the so and XML format of the messages. But of course, if you use some of these lighter weight programing languages, then you might want to use rest in JSON. Formats is typically preferred by programmers using those lighter weight languages for APIs and web services. A typical integration pattern is to use a API gateway or web services gateway because they act as the enforcement point and they can call to, you know, the same central PDP service or authorization service for just for decisions. And this is typically non-intrusive to the developer because they, you know, they publish their API or web service in the gateway.
And then you just configure the gateway to determine which ones need the external or dynamic authorization applied to them. And as a final integration note, we can also apply this model to the database tier in here. Now we have a SQL specific interceptor that, you know, stops the query that goes to the database, sends it to the authorization service, where again, the policy is control access to database tables and sensitive columns within the table. And here, instead of returning permit to not, you can actually modify the sequel in, on the fly, so that when it executes, when the updated SQL executes only authorized data is returned to, to that user, that's called the database then wrapping up here. So we can get to our Q and a session. When we think about going from role based to AAC based, this is what I mentioned earlier.
You know, if you go straight from one to the other, that is you try to map your role based system into AAC policies. We suggest that that's not, not the best approach. You know, you don't want to, to do this, but rather you want to take a step back and think about this from an AAC perspective. And primarily this is, you know, thinking about, again, the natural language statements that you're trying to implement. You know, doctors can view medical records of patients within their own department that can view all the, you know, the detail medical data only for patients that are assigned to them directly based, again, filtered on the consent of the, the patient. So there's a fairly complex set of rules there that you need to think about first. And then you can decide where along the way that you incorporate your existing roles, of course, in my example, doctors or different kinds of doctors being those very important roles. So this is something you want to consider. You do need to take a, a step back just for a moment before starting on this journey to dynamic and, and, and interview based authorization. So at this point, I'll, I'll thank you very much for listening to this comments. Hopefully we've sparked a few questions that you'd like to discuss in the next session and Matthias I'll turn it back over to you.
Yes. Thank you very much, Jerry, for that great presentation. Yeah, we are now coming to the third part, as you said, which is the question and answer session. There's still the opportunity for the audience to add some final questions through the questions panel within the go to webinar software. So I would like to ask you to do that first question that that is from the audience is I just read it out. It appears that Jerry is recommending that policy modeling and ABAC providing dynamic assignment of privileges to users should be closely assigned with policy based entitlement decisions when a logs in and attempts to access the application. Is that correct?
I, I think it's one example. I, I, I believe that's, that's true. Yes. So when the user logs in, you can actually make a call to the authorization service in essence, to give me the entitlements, you know, give me the roles that are assigned to this user, or give me the menu items that they can view in this Porwal. So, yes, that is a very valid use case for dynamic and attribute based authorization if I understood the question. Okay.
Yeah, but it's one, one use case it's not the only it's one possible use case, as far as I understand it. Yes. And, and one question probably when, when, when we use roles for provisioning, could the, could such information also be used for runtime access control for, for something like that. So many organizations spend lots of time and money and, and, and having a maintenance process for, for various sophisticated role models where you you've you've, you've looked at that already, but how can this enterprise knowledge be, be reused or at least not completely flow way?
Yeah, that's, that's a great question, too. I think this is an example of extending those existing roles that both you and I talked about. So maybe not every role for provisioning can be used in access control, but I think already most of them already are used for, for access control. So we can take those roles and extend them with other contexts as, as needed as we both described during the session.
Okay.
But again, I think, but Matthias, I think it, again, it points out to the reuse of existing investments in the designing the, the, you know, the security model and the access control model that we, we want to make sure we use that information and, and leverage it and extend it. Not that we, you know, dismiss it or dispose it.
Okay. I have two questions which, which focus on, on the externalizing aspect of, of, of the authorization process. First is a, the question whether having a centralized or at least a, a, a central authorization infrastructure, can this impose to be a single point of failure failure as well. And how do you scale such a system to make sure that, that, that yeah. That is available as, as, as required?
Sure, sure. As I mentioned during my session, I, I, I avoided that for the moment, but for high availability, resilience, and performance and scale and capacity, what you typically do is implement multiple instances of the decision service component of the aback model, and you can implement, and this is what typically customers do. They implement multiple copies behind a load balancer. So if one fails, you know, the others can take over. And we have customers that even have, excuse me, multiple data centers around the world, you know, for a, a business application that's operating 24 7 and in a global fashion. So these are, and another way to do this is to actually embed the decision module within your application. So you can almost use the like cloud elasticity principles, you know, as you add more copies of your application for scale and capacity, you, you get it, you know, the, the authorization service along for the ride. So you, you can scale up and down as needed.
Okay.
Cause you, you, it's certainly very true that you want to design the authorization service so that there's no single point of failure. And, you know, we've had customers deploying the technology for five years or more without a single outage, you know, so that's, it's certainly possible to do this.
Okay. Thank you. Another question Richard is quite closely connected to that is that one, one person from the audience speaks from experience and says that performance is inverse to the amount of runtime attributes that are evaluated and retrieved. Is this a challenge that you're seeing as well? And how do you overcome that?
Absolutely. It's a, I would, I would say it's a challenge or a consideration and that the questioner is, is absolutely right to, because there's really two points of latency to think about. One is from the application to the authorization service. And so there's, you know, different ways of doing that very efficiently, including, as I mentioned, embedding the decision module within the application. So you're doing an in memory call, but then looking up attributes. So the, the response time is going to be directly related to the performance of the attribute sources. And you have to be careful in your policy modeling to, to know the response time characteristics of those data sources. And, you know, this may be even something that you need to improve if it becomes an issue. And there are ways of, of providing cashing so that you only look up data as you need to, or you can even use a virtual directory. As I pointed out in the one slide to pre-load a cash so that the data is readily available for the authorization service. But yeah, there, there are a number of ways of dealing with this and we've, you know, typically can work with a customer to find an optimal recipe for, for success here.
Okay. Another question from, from your experience, are there any issues when it comes to auditing and regulatory requirements, especially when it comes to providing evidence for past access decisions, this something that yeah. Auditors or regulators really need to make sure that they can later really understand why and, and the decision have been made as it have been made. How do you document that? And is this something that audits accept because they're used to roles,
Right. Well, this is very interesting. And I'd like to actually extend the question with, with my answer here. So there's, there's two ways to look at this one is the, the past results, right? The audit log of past access attempts. And that's really to the heart of your question. So the like many security systems you can configure how much data is collected. So for example, you can capture the request. So you have all the attributes of the requester. You can capture all of the policies that were considered for evaluation, and then, and then the actual results and all the attribute values that were used. So for example, if I needed to look up in the directory or database, what role or roles you were assigned, or what department you were in, you know, all of that data can be captured. So you can basically reconstruct what happened, you know, in six months from now, if you wanted to look back to see if you know, the transactions that were executed today.
So that's basically a, you know, typical audit log of what did happen. And furthermore, you can spin off this log data to something like Splunk or other S E IM tools for analysis on things like, you know, correlating what's happening in the authorization service with what's happening in authentication service. You know, so you can do that kind of analysis of looking for patterns of bad behavior, but I think what's also important. And so to finish the, answering the question. So I think auditors clearly recognize that kind of audit data and, you know, can, can accept and deal with that, that kind of audit log data that this kind of authorization service collects. Furthermore, you can actually run analysis of your policies to see what can happen. And I think while auditors, sometimes ask this question, you know, it's sometimes difficult to answer it if you have, you know, a role or a group based model, but with, you know, there are tools to analyze the policies. So for example, I have a V I P clients in my wealth management system. I want to know if there's any possibility that anyone other than the assigned banker can access those records. And so with, with analysis tools, we can actually examine the dynamic and aback policies to see what the answer is to that question. So we can determine if there's a gap in the system, or if perhaps someone is inappropriately assigned an attribute that they should not have.
Okay, great. One last question, because we are running out of time, but it's closely connected to that in relation to the evidence. Is can you attach a risk to policies to focus the audit?
Well, I'm not sure I understand a risk to the policy. You, you certainly can attribute, I'm sorry. You can add an attribute that is a risk score. So for example, you know, the user logs in with their, you know, one time password token, but it's from a device we've never seen before. So the, the authentication, you know, the adaptive authentication service may assign a lower risk score to that. And so in your policy for certain kinds of data, you could say that, you know, the risk score has to be five or greater to access this data. So in, in that regard, you can certainly do this and that's, you know, a great example of how you can extend your, your role based system to add this kind of context.
Okay, great. Thank you very much. We are close to the end of this session. There are a few questions opened, and I would like to encourage everybody who enter, enter the question to get in touch with, with Jerry. And Orme the, the mail, the mail addresses will be published along with the, with the recording and the podcast. I would like to thank Jerry for this great insight into the technology of, of aback and to, into the idea of extending role-based access control with dynamic components. I would like to thank the audience for spending one hour together with us. I would like to invite you to join us in the next webinar. Maybe we can see you in one or in March next in may next year for the EIC. Thank you very much. Have a great day. Goodbye.
