Enterprise Role Management Done Right: Building the Bridge Between Business and IT

Welcome to our a call training enterprise role management done right building the bridge between business and it, the speakers today are me, Martin Ko, our founder and principal Analyst at a Cole and Dr. Hostel senior Analyst at a Cole. We will talk today about enterprise role management, how to do it and how to use it to close the gap, which frequently exists between business and it, what we'll talk about today, that's based on our long year research and advisory experience.

And there are a lot of things I think, which helped you close this gap to do an role management really based on what the business requires in a way that it can use it. And that it really brings well you'll make sense for both parties. So that's what we will talk today about keeping a call itself as an Analyst company, we're providing enterprise it research advisory services, decision, supporting networking for it. Professionals from vendors, system creators, and end user organizations. Our research services include reports and custom research.

We provide advisory services and events, our main event. It's the European and cloud conference, which will be helped next time in May, 2013 in Munich.

Again, it's definitely a conference. You shouldn't miss some guidelines for this training. You're muted centrally. So you don't have to mute around with yourself. You're controlling the features. You're recording the training and the podcast recording will be available. Soon. Questions and answers will be at the end. You can enter questions at any time using the questions feature, go to webinar. We'll usually pick them at the end. In some cases, we might also pick them curing training. So let's directly start with the content design of this training, why enterprise role management.

So enterprise role management is what really helps us to map the business reality to it entitlements. So the entitlements saying who is allowed to do what specifically within systems are one side it's more or less the it view. And that's a very important thing. You look at what we have seen over the last few years in the rise of compliance requirements into role governance has today.

And the questions are asking on the other hand, business thinks a little bit different business thinks and their drops and their processes, their function, and the other things I think in roles someone has in the business. And so it's about mapping these two views. It helps us to in the year of governance, so first using risk management and including fulfillment of regulatory compliance that requires control and management of entitlements, according to the business functions. So we can't do it technically from it perspective. It's about what is the trouble of this person?

Does he need this entitlement? Is there segregation of duty conflict and all these things, enterprise role management done right? Allows business to describe itself in a way that can be consumed by it so that it can match the entitlements to this inscription scription done. Right. And I think that's the important thing. If we have seen a lot of projects out there around role management somewhere, very good. Some others were maybe not really done, right? It builds the bridge them between business and it, and both sides can work with their view. There's a mapping where things come together.

I think one consequence might be that it will have to redefine entitlements in some cases, maybe sometimes also frequently to fit them to the business reality. But I think that's a thing which could be done in practice over time and which has to be done in some part of time, because at the end of the day, business drives these things and it's, this is for whom we are doing it. And so we have to do it in a way that it fits to what business sees, not the other way around and regarding enterprise role management.

There is no other proven approach for doing that, despite what might have been said. So there are some ideas around this, but the only thing which is really proven to build this bridge and to manage entitlements that's enterprise role management, but is not only looking at roles. So enterprise role management, the way we describe it goes well beyond roles. And then it's really an approach which serves for these needs. So let's move to the next slide. Thank you Martin, for setting the, the scene.

So before we go into the details, some words about the basics, what are roles, what roles most commonly understood as functional roles. This means bundle corporate functions out of some functional enterprise model. If you have it at hand, even better, if you have an oriented object-oriented business model at hand enterprise model at hand, this is takes you even further. So what has to be done to receive functional roles? It's pretty simple.

You just select the appropriate functions out of the functional enterprise model, add them to the functional role and give them a meaningful name, which is very important for further processing. Well, this is the function role. This sounds simple, but is it enough for grant in excess, which is the basic idea about the role based excess control of the RBAC?

Well, to be Frank, it's not. So something is missing still, and this is something that a addresses as well, but in a different manner, the information in this model, isn't sufficient to manage all entitlement entitlements. So we have to add something. We should narrow the focus and how can we do it first, let's consider the objects that make up the organization and then probably we will find the measures to do that. And so what are the privileged determining informations that we need, perhaps the next slide gives us some insight?

Well, first of all, I mentioned functional versus object oriented model. And to give you some details, what are the differences I listed the functions here? So the functional model obviously focuses on the function within organizations, whereas the object oriented model focuses on objects, interacting objects in the same organization. So it's a bit different perspective. Functions are associated to business processes. As we all know, they are the most granular elements in processes describing them, requires some organization and maturity. So you need to know what your organization is about.

This is quite in line with the traditional business organization, which is more or less a hierarchy of functions. It's easier to uncover and to communicate in comparison with the object oriented model, but it only delivers functions. So coming back to the object oriented model, these objects, these interacting objects, objects that I mentioned have their methods, which are pretty much the functions we have seen before. They introduce an additional structuring layer, which is the important and interesting point.

So you need not to deal with the, the multitude of functions, but with fewer objects. So it's structured. So these objects are more powerful and, but on the other hand, more demanding to develop and they cause more initial effort. That's why we mostly see functional models and they're less common, but nevertheless, worth the effort. Okay. But now at the next slide may go on with our core topic. So I mentioned the objects that make up the organization relevant, relevant in this context. So what is the organization? That's have an abstract view.

And in this abstraction, the organization is made up of processes, roles, and rules. They express how the enterprise is organized. So we can take them as a generic template. It has just to be populated with real things, person, systems, and so on. So this is still abstract, not yet the physical inclination and, but this means we are not confused by all the physical implementation details and have a more concise model that leads us further. The model modeling approach is that the business processes express the organization's dynamic behavior dynamic behavior.

This is, has to be emphasized. There are in most cases pretty well understood. And we present the essence of the organization, all planned activities, but these processes of course are made up of elementary reactions. So atomic activities, this is to distinguish them from the aggregated functions, which are sub processes. Those are pretty much what one person does in one point in time in one location. So when time changes person changes or location changes, we have a different activity and these activities they are performed by, by these functional roles.

So here things come together already, the functional functions about to resources, obviously. So, and here, something comes in that we call constraints. So these functions at the first, the first time now are constraint and constraints more or less further restrict the roles, ability to perform activities. So not on all objects, just on some constraint express the privilege, determining information dimensions like, and now it becomes interesting.

There are several dimensions, organizational unit, region, contract type customer group, and many more, depending on the organization, the resulting business role can then be used for excess control. So we have to add restrict constraints and we receive the business role. And then the intended privileges we need for ARB will results. Okay. On the next page we go on in this discussion. So obviously processes and roles cannot be modeled independently without being incomplete. They belong together.

And This is the first statement, but secondly, only after taking the constraints, the several different constraints into account allows us to deriv entitlement information for the access from functional roles to information objects. And this picture to our opinion is pretty much straightforward. And it's even easier to comprehend than the stand model, for example, which is referenced by the AACH standard. And so I think it's easier, but still finding roles requires good and explicitly documented knowledge of the business domain. So you need to know how your business is working.

And so this means you have to express them in form enterprise process model. And as I mentioned already, the enterprise role modeling is included in the process modeling.

Otherwise, if you don't have the roles that process the processes, it's not yet complete. Obviously this is all not a technical task. This is a purely organizational task and it doesn't require technical skills even, but it can be used to implement to technically technically implement excess control. Okay. So let's move to the next slide. I mentioned the Stanford model for excess control. I don't want to go too much into the details, but I think it's worth to show this model where we have represent representations of the organization departments, authorities.

And as I mentioned already, we will use it for, we will use the roles for granting access to systems. There is a system side as well. So the internal and the system view, and this is I think the main message that has to be carried by this model and where we still are on common ground and both agree. It has to be modeled on the business side, but has to be applied to the, the system side. So we obvious need knowledge about both, and this is what makes this discipline so difficult that business and technology have to be, have to jointly work together. Okay. Next slide please. Okay. Thank you.

Hears for that part. And I think it's, you've, you've pulled a grant here for, for really explaining some basic concepts. And the question, especially when you brought up constraints, the question is really, is, is it really enterprise role management? So it's about processes, functions, constraints, rules, entitlements, and roles. And I think that's very important to, to understand enterprise roles. Management is far more than trust.

Looking at roles it's really about aligning your business and your it describing your business in a consistent way, putting it into a simple model model, which can be handled, which just be, which is really the, are the core, which are as a said, an established pattern to use. So it's more than this constraints are a key element because they are tailoring roles. They are defining what was in the role could be done by someone. So can we give her an approval above 100,000 Euro or not all these things that a lot of other things we'll talk about is more in detail later, process and functionary.

Now what leads to function a role. So that's the relationship and the it view like quickly shown Stanford model, which will be shown more in detail later. I'm kind of into play as well. Nevertheless, even while, while the term role might be a little bit too narrow, we still recommend the term enterprise role management because roles are at the core of this concept. So the cosing are roles. They are established. The term is established and roles don't describe the entire organization.

So they really are more the link of the business process and the people, which is the, the importance thing to the it. And that's what it's really about. There are some other things and some other discussions there, there's a discussion about Rach versus AAC. AAC is the attribute based access control. Rach is the role based access control. I think it's more theoretical discussion because for sure, Rach in, in a, in a core concept without constraints and other things, it's too limited.

I think everyone knows it's not sufficient, but our, or a role model in the way we describe it allows to do a lot of things. Abe sort of describes everything. You have a lot of attributes who say, okay, if these attributes are here, then someone's allowed to do that.

In fact, roles and constraints are attributes. And you could just say the roles, one attribute and constraints are other attributes, and then you're exacted aback. But a fundamental thing, first of all, is that it doesn't highlight the central roles of roles. The central position roles have in this concept. And it doesn't help us to define the roles and it doesn't help us to abstract the organizational reality.

It's the, it only view. So it doesn't really help us. We need a model, which is based on the business view. So enterprise role management from my perspective is AAC put into practice AAC matched to the business and this maps the need for having modern roles with the need of a business driven design. What I have to do on the next slide first is giving a quick view on the basic enterprise role model in the, within the next few minutes, we'll show you more expanded views on that, but here, I just wanna show you the key role concept and the relationships.

So we have an organization which has processes. These processes have function, which are mapped to functional roles. On the other hand, the organization has constraints. So these constraints are something derived from the organization, which are in fact, based on, I would say business rules. So constraints derive from not only business rules, but also for organizational structures and other things. But in many cases, it's about saying, okay, someone is not allowed to do that because of this. And he has constraint approval up to 100,000 above 400,000 management of sales persons only.

And that's zip code area, whatever, both of these things. So functional roles and bus and constraints come together in a business role. So the business role in fact is something which is deriv from the functional roles and which is sort of tailored or localized by a constraints and identities are associated here. So business roles are assigned to identities.

And on the other hand business roles that are assigned to entitlement and the entitlements are in fact, the actions within the, it that's, then the it side of things that you can't extract entitlement, first of all, from a business perspective and then assign it to what has to be done and what could be done in it. And that's what we see as the basic model, which like you will see them can be altered and expanded a little in practice depending on your specific needs. But overall, that's the basic model you have here.

And that allows you to describe a business view, map it to it, with where you end up then with actions on an information object, which could be very granular with systems. So it could be aary cross screen trust saying this person's allowed to use the system. This person is allowed to use this email account. This person's allowed to use the share. It really depends on it. Doesn't limit and narrow down anything to a specific system. You having said this, we will dive deeper into the details and I will hand over again to host, Thank you, Martin.

So roller center organization, Martin mentioned already, there are several important objects we have to deal with. And why, why does it happen that an individual so represented by digital identity receives the role?

Well, it all starts with having an agreement, the identity, the person, mostly it's the person engage with the organization. And finally they come to an agreement. So employee contract or something, some different contract is closed and this more or less expresses the role of the individual already for role modeling. This is mostly not sufficient. That's why we cannot simply use the contract. Let's say the employee contract for role-based access control, but most of the information can be already derived from some agreement.

And obviously each role needs to have this firm foundation of an agreement. Otherwise the role within an organization would not be justified. So here again, we see the identity which has a contract with the organization. So in between the organization and the identity, there's a contract, this contract most often is of some contract type. So we have, again, the class and implementation relationship here, and the roles most often are derived from the contract type.

So some bank clerk has a contract type different from some salesperson and the functional roles most often can be directly derived from these contract types, various constraints, further detail, the contract type. So they are the elements, the parameters added to the type. So to form the individual contract, and these parameters may express the region where the salesperson is assigned to our, the organizational unit where some bank clerk is allowed to act and the contract type of course of the employee, if it's a contractor role or if it's a fixed term role and so on.

So, and then on the next slide, we will dive a bit deeper into these details. So the starting point obviously are job descriptions. This is in most cases, the best starting point. So if you have a contract closed, most often a job description is documented, or at least in mind when closing the contract, this is something you should have at hand when you do role modeling very often.

And in a volatile word, there are not permanent positions to be modeled, not only permanent positions, but also temporary positions, which are often part of projects and project a project is defined as a temporary endeavor. And in our context, we simply consider them as being temporary organizational units. So they fit into the organizational structure, but not forever, just for a limited time. So this is the type of constraint as well. And so these functions are derived from processes. As I mentioned already, this is all an integral part of the organization.

And now let's see in the next slide, what, how we can make use of it. So you see at the upper right corner, a small sketch of our object model of the interacting objects in the enterprise that play a, their role in role modeling. And one of the, obviously of the most important objects is the identity, the digital identity. So what is an identity? There's much confusion about it as it's defined differently in different disciplines here for our purpose in identity and access management, the digital identity is simply the digital rips and representation of the individual.

So the individual projected to our needs. So what do we need to know about the individual? And this is the digital identity. This individual may be represented by more than one digital identity. This should, should keep this in mind because this can happen. But these digital identities always have to point to one individual. So the individual has to be, we have to be able to trace it back to one identity to one individual.

So, so what is the lifetime of a digital identity? Well, as long as the interest in the relationship to this individual lasts, this means if an individual is employed as an employee in a large organization, for example, after a time it quits and comes back as a consultant, it might be of interest for the company to track this. I know that chief security officers are quite eager to know, especially these kinds of relationships when someone has different roles and shows up again, and then they ask might they have some excess rights inherited from the former physician.

So on the other hand, there might be legal restrictions, legal regulatory requirements might restrict this use, and we should keep this in mind. And there is a contradiction between compliance and data protection requirements, which are not always easy, easy to solve. So there are two sides to be considered and some more guidance can be drawn from, well, it's called the loss of identity drafted from Kim, came from Microsoft. Originally, of course, those are not real loss, but it's the best we have at hand. And so we should mention them.

I cannot go into deep detail, but I recommend to read through Kim Cameron's block it's user control and consent. So the user has to be, has to sit in the driver seat and give his consent about what elements of the identity can be used for which purpose. Of course, the principle of minimal disclosure, this is a general modeling principle, but here it becomes more relevant. So we should just use those elements that we really need. We need justifiable parties.

There might be the possibility of a directed identity, which works to one side or only I won't explain it into, into detail because the time were not cover that there's a, we have to deal with pluralism of operators and technology. So the identity must be designed with these purposes in mind, there's a human integration possible and consistent experience across context. So the overall user experience has to be considered as well.

So please, if you're interested to read through Kim Cameron's blog and the identity management, it's very often mentioned as identity and access management, but it's a discipline on its own discipline to express it in Latin words. So a very standalone discipline, which can be used even if you don't have any assistance. And if you do customer relationship management or partner relationship management, there is a core part of identity management included already. So it's neither part of role modeling nor of excess management, but we needed to mention it here.

Okay, next slide please. The functional role. I mentioned it already, so I can keep it a bit shorter. It's made up of a bundle of business functions, derived from the enterprise model.

It, yeah. Obviously represents the functions, the task that have to be performed still unrestricted. So as I already mentioned, it's a projection to the enterprise functional enterprise model it's draws and extract out of it. And I also mentioned that it cannot, it's not ready for use for role-based excess control. So to grant access to information objects, we have to add something to it in special cases is it can be used, but those are yeah. Special cases that can be generalized. And also mentioned if there's an object oriented model in place.

In fact, it's a class based based model. When we talk about it, then the functions come with some constraints already because they are bound to information objects, most often information classes, and they can be, we have to, in this case, keep in mind that some constraints, the binding to the information object is in place already. Okay. Next slide for the next object, please, the constraint is very important and difficult part of the whole model. It does nothing else then narrowing the focus of the functional role.

So the functional role would grant a universe of possible access to information objects. And this has to be now constrainted by or restricted by the constraint and would like to mention some well known examples. For example, authorization levels, bank clerk might be authorized to sign contracts up to 1 million British pounds or us dollar dollars, but not above. So this is authorization level to limit the transaction value by limit by value. But you can also limit the scope to a certain organizational unit or to region or even to projects or to information objects.

There's a fine structure to these constraints, obviously that we have to look further at. And even to the value bound constraints, there is a fined structure. They can be expressed directly in amount of money. They can be expressed indirectly without stating the amount of money, but with some influence on amount of money. So for car renters, for example, the allowance for kilometers or so can be expressed in hard dollars at the end, but in the role model, they enter in a different indirect format.

Well, just quite common that more dimensions lead to further restrictions of the role roles for privileges as rented by the functional role. So this is for example, the contract type, which is quite important, and employee might be granted different privileges than a contractor or interim manager. This is something that adds to the more common constraints like region and organizational unit information, object, and authorization. Obviously there is a full universe possible of constraints. And when coming to role modeling, one has to discuss a bit deeper into it.

Some of them are listed here, region organizational unit, where customer group is quite common. So for wholesale customers or retail customers or corporate customers or not customers, but dealers, which in some cases are intermediate a mediator between customers and the company can be seen as a customer group as well, authorization level. I mentioned it a project, which is temporary organizational unit. And I also mentioned that even certain information objects can be used as a constraint.

So access is simply restricted to this object, the contract type I mentioned already, but this is an open list. And for each enterprise it might be different. Okay. So far Martin please.

Yeah, I think the next, I just want add a little bit to the constraints thing. I think we will see increasing number of constraint types will be used in the future. So when context comes into play, we will see more when dynamically used things here.

So I would call it dynamic constraints so that when we do decisions, it might be that we pick up the information about a device used at that point of time, the location, the system health status, the strengths of falsification and other things, which are in fact information, which are associated to a business rule, which we have sort of implemented by the constraint. But in that case, constraint is much more dynamic value. But in fact, the more we move towards dynamic authorization management. So things like, for example, are based on exactly or commonly called entitlement or police deserves.

I tend to use the term ization management, the more we will do there. And the interesting point I think is for this entire thing, even the things which are more popping up now, which are in some cases, even trust more, the horizon of it can be easily covered by that model, the monolith flexible enough to do it because that's the business view of the context and this fits imperfectly into our model, but let's move to the next track, the business roles fourth. Yes. Thank you very much. So the business role is something where everything comes together.

So this is really the structuring, the, the central structuring element we need. But as Martin pointed out, this needs not necessarily to be a static object, it can be created on the fly in case you have the constraints documented in a way that they can be expressed as rules and applied dynamically. In this case, the business role needs not necessarily to be stored statically, but created on the fly and used, well, this was Schutze course, but generally to express it, this business role should need all information necessary for privilege assignment on the business level.

So not necessarily on the technical level, there might be some dependencies that are not expressed here still, but by the introduction of the business role, the well in a purely functionally defined model, we have all information together to bind it to information objects, the functions, how are they bound to information objects? And as we pointed out, this is done by constraints. And when we have this functional role at hand, so defined on business level, how access can be granted, we still have to bring it into life. And this is done by linking entitlements.

So elementary operations on objects as defined in a Iraq to these business rules. This can be done. This works, but there may, might might be cases when the systems offer some role support already. And if this is the case, we might introduce an intermediate layer, the so-called system roles. As if we look at reality, most often we don't have the information object and directions at hand, but we have systems which grant access to the information object. So we have to deal in real world in the physical model, we have to deal with the systems.

And so if you are technically managed to bind the information objects, strictly world driven to the functional roles, you, you might not need the business roles. I mentioned this already, and this is for good news for dynamic authorization management, but in most cases in real world, however, we need to consider them as the static. So means persistent objects. And this means you have to store them and you can imagine them as some triple of references only. So they don't really contain information except references to other models.

And so this is the reference to the business role, to the functional role, to the constraint and to the underlying entitlements are if you have it at hand and introduced it or system roles, and yeah, this finally leads to the entitlements then. Okay.

Yes, slide That's, that's what we will cover right now. So the entitlements that's, I think one of the areas where we know come closer to the it, because at the end of the day, like what we said, it's mapping this model to the it, and it, that's where we have to touch point around entitlements entitlements are. And for sure, maybe by implementing an enterprise role management, using a tool, but from the, the construction perspective, from how to build a model it's until now it's only business and here's where we enter sort of the touchpoint.

And that's what I will talk with about us in the next few minutes, how to really map this right now to the system, to the it reality and what we need to, to do there. So the entitlements we've had them before their elementary tract of access management. It's the entitlement elementary privilege. It's in our bag, it's defined as an operational object, which is a very broad definition, which is helpful because we can use it to describe everything, not only an, a ACL max control list entry or whatever, you can use it for virtually everything.

So in the first case, it's not recommended in the worst case. It's just saying someone is allowed to access the system, but we have several system where we don't have the necessary ity there. Yeah. So when we look at the sort of lower part where we have the identity to the business role and the entitlement, I want to introduce two other concepts and a little bit on the lower level than there. So one point is the user or the account. The other thing is the it role we might have there, it's an optional thing. I will talk about it.

More details later, these are sort of technical artifacts coming in systems are there. And usually they don't implement a well defined enterprise level concept. So they have their, their own specific view, which is very systems centric. Even when they, they talk about business roles. In some cases, usually it are not business roles, something which is very system depending. So there's a mapping required between the reality business and the reality of it.

And maybe also reality of it has to change in some cases, which frequently in practice can be done using a sort of a migration pass, but over time, for sure it should become closer to the business. It roles can work as an intermediary area between the business roles and the entitlements to reduce complexity. I will talk about this, especially when it comes to cross system entitlements, entitlements, mad map, or will map the system specific concepts like system roses or trust systems like class allow denied. So they are in fact sort of the, that the highest level of things exposed by a system.

A system might have a much more granular access control concept internally, but that's what is exposed and what is used by the business, what is used for mapping these things. And if you look at the identities and the accounts and an identity has a user account, or many user accounts associated is user accounts are used for logging into specific systems, but a person that could have multiple identities like ours explained before the identity, again, could have multiple accounts. And that's really the technical thing.

So that's a little bit, the next level of detail we are bringing into this model. And as I said, one of the, the important technical artifacts here is the it role. It's an optional construct, the weld use of this. And I think that's very important to understand there's there are some areas where we clearly say there's a weld use and there's an in use well used is around combining entitlements, across systems, which are largely logically tied. For example, the entitlements you have on operating system database and application level, which you all need to perform a specific business function.

Entitlements are, that's very important. The definition are per se system specific, but access needs to be commonly granted to combinations. And that's where it's really a well used to make things easier in, well, it uses to combine entitlements from one system in that case, it's about rethinking the, the system concept so that it exposes exactly the entitlements, which are used to the, the cautious level of granularity we can provide, which still makes sense.

And why's, for example, segregation of duty conflict is something we quickly touch later on because it indicates false and system level management of access control that should be corrected there and not by using it roles and other in uses to reduce the number of associations between tile months, business roads that might be, might be helpful in some cases or appear helpful in some cases. But the other side is you add an additional layer which increases the complexity of the overall concept.

So you will end up with a situation where you have a lot of mappings of entitlements to it, roles with one to one mappings. You have the situation business role can map to it, rules or entitlements. You have to be very careful. Nevertheless, I think overall it roles.

If you, if you have a lot of trust system, things might be a very helpful construct. It will, in that case also slightly increase the complexity.

However, it really is a very clear rule for definition. And I think that's always a guideline. If you can, if you have a, a clear and well defined rule for using a artifact technical artifact, it might make sense. If you don't find a key rule, then you better leave it. And that hero they're optional. They might bring value, but you have to be to look at it carefully and decide on, do you need it? Don't you need it. The other thing is the account and our general model is person might have multiple entities, might have multiple accounts. So that's what you really see.

And a person might have many identities. He might be the employee of an insurance company. He might be a Lance insurance broker at the same time in the customer of the insurance company. And he might sell a contract to himself and approve the contract using all these three identities. And then we have a segregation of duty conflict. So each identity has one to many accounts, which are the users at the technic level. We have to bring them into the model and understand where they come in. That's why we have them from there.

And we have these system level concepts, like system groups, the system itself, or whatever, where entitlements are generic. They describe an operational and object at the system level. These might be different concepts. And we have to have a sort of a one-to-one mapping of the highest exposed level of a system to what we understand as an entitlement. In some cases, entitlement also called system rule, but it's sort of redundant use of a term and typically leads to a little bit of confusion. So entitlement definitely is the better term here, but systems have to expose exactly the privilege.

PS business required. Nothing else that might over time require the system level of concepts are filed. If they don't fulfill that requirement, it's something which then becomes very clear. When you have built your business view, then you have to maybe do an accept there and goes through the system use, which frequently are very technical driven. And at least over time have to be reconstruct. In some cases you might say, okay, because I need to implement it.

I start with, let's say more, more complex mappings of business roles to entitlements at the beginning, but that shouldn't be a long term solution. So really then understanding. And I think that's where business and the concept really helps it because it says that's what, what is the business reality? These are the entitlements business requires. So ensure that your business is expo, your systems exactly expose these things. Then it knows, okay, that's what business understands.

And then we can construct our systems according to this, and don't have to guess what the business might need as an access control. So it brings a lot of value. It makes things a lot easier for it over time. It might be migration or, or redefinition step at the beginning, but over time it's life will become much easier. So it makes sense. The assignment is the identity becomes user. So assigning the business rose to digital identities sort of creates the object. Use this identity uses the business role. That's where the act of role-based P assignment is done.

In reality, the identity typically is assigned several business roles because most cases that feasible to limited one, at least for, for the typical employee, we are, we are looking at, if you have the customer, it might typically be a one to one mapping. If we have the external, it might be many cases to one-to-one mapping. So it really also depends on the type of identity here. And that's what we are doing.

The context the object uses often in this context, the object uses often calls user, which in fact means the relation expressing the use use might be restricted to a period of time by a beginning end date, which we can again, do using constraints or whatever. So it's one thing we, we can put in here when we combine all these elements, then we end up with a picture which is a little bit bigger than the one I started with originally.

So at the beginning I had a picture which folks, organization and process function, business road, entitlement effect, and said, that's it what we are, the identity, what we are looking at. We also had the context in, we had the person in, we had a user account and we have the optional it role in. So it looks a little bit bigger, mandatory, everything that's is optional. Optional are things like context related business rules.

Cause they're not applic couple yet in many situations, the it rule which we can replace the contract and contract type could be expressed through process and constraints. But there are, there are frequently and there are organizations where we can build a lot on contracts and shop descriptions. There are other organizations where things are little bit more Fossy overall.

It helps to have all these concepts in and to say, okay, that's the picture, but you might start with a, like you've seen on the pictures before with a little bit more limited view where you really say, okay, that's where I look at functions, function, role, business roles, constraints, entitlement, and then you can add it. And the important thing is this model is made to support all of your business reality and what the it on the other side needs, not only for today, but also for when you have to do more in the context, dynamic authorization, management context, and risk based operations.

It's built into that model. That's where I want to give back to T To Some up some of these things and, and go to the next step. And afterwards I'll bring in Some, thank you very much, Martin. So we have rather impressive model already aesthetic objects. I mentioned AACH several times. And so I want to give you a quick overview where they, how they compare, where in AACH we have the user who is assigned a role. There is a dynamic aspect with sessions, rarely used only. We have the same operations on objects as we use it. They're calling it permission.

We call it, we before called it entitlement. We can call it permission as well, but good to know it's identical. So we introduce the functional roles, separate from the constraints to form the business role. And the assignment of this business role to the identity is called you. So this is pretty much our model just to compare to AACH and let's go on to the next slide. There is always one questions. Question arising when a role model should be applied, or even if it should beforehand constructed, how do we find models? How is the correct approach? How should we go on? Is it top down?

Is it bottom up? Well, it is even possible to go bottom up as there are analytic tools who take the whole information base of already assigned privileges entitlements and analyze them in a intelligent way, found out frequent aggregations. And so you can, could consider them as roles, but all the flaws and which you will finally find out are still in this creation. So obviously the top down approach is the peanut one. And do we consider it as the correct approach, starting from the business processes and so on, as we pointed it out and then finally map to system level artifacts.

Whereas the bottom up approach is time for the business reality and it might lead to some problems. Nevertheless, it has its merit. And a combination of both to our view is the best way to start top down and use the bottom up approach as some quality assurance means to verify if we have found some meaningful groupings in our top down approach.

Okay, next slide please. Yes. And this exactly the top down modeling approach, we mentioned several parts of it already. So it might, although it's bit confusing picture, the elements should be known to you already. There's a process made up of several single functions. As I mentioned, one person at one time at one location. So this is to separate these functions. They are performed by roles, still functional roles, but when we bind these roles that they access several resources, they may be constrained already. So the information objects are on the bottom level they offer.

They are, or they can be accessed by several functions. And if the functions are separate, you have a functional model. If the functions are tied to the information object already, you have a object oriented model. So there you have the choice and this is how you can find the roles. Next slide please.

So, but these are the static objects. And finally, to bring life into the picture, we need some dynamic aspects. So we have to introduce processes processes for the role model itself. So these processes are still of course, highly generic to have a starting point, what would be essentially necessary? So what do we need first? First of course, we need some model maintenance, which means the maintenance of the models, objects this to us, it seems to be the, the natural starting point. So this means we have to maintain all these objects.

First, the function of our maintain in this context means to create them, to change them, order them in a way even deleting them. Whereas division is subject of its own. Most probably they are archived and deactivated, but not deleted only after, or, or deleted only after some time has passed within. They are legally allowed to keep. And after the time we have to de delete them, so same applies for the constraint for the entitlement and for the central element, the business role, of course.

So maintenance processes are on this level still rather simple, but this picture changes when we come to the next night. Yeah. And maybe trust side note from my side, there will be an upcoming Al training online training, which goes much more in detail on all these process of model maintenance and the UVF standard process in that area. Okay. Understand? Yes. Obviously this role, the, the processes assigned to role modeling might fill a webinar on its own. And this is much more than we can cover here in this single webinar. Yeah. Then the organizational integration.

So what do we need to have these processes all implemented and the responsibilities implemented what we need, first of all, functional enterprise model at hand, it should be there in a way, at least functional. If you have object oriented, it's fine. So it should describe the business processes, the functions and the constraints constraints are most difficult to find. Of course you should determine the ownership. Every object needs an owner. If it's a process, a rule, a role, a system, even the identity needs an owner.

So the superior, the line manager, the so every object needs an owner needs to be defined, which sometimes creates pain in the organization. You need processes, processes from maintaining the entire model have been well defined and executed and maintained. So this needs to be in place and you need some, or we recommend an information centric approach, which means at least in more advanced implementations, you should move away from the purely system centric view and focus on the information objects it's anywhere necessary.

If you move to something like an service oriented architecture where you don't have any applications any longer, but some different forms of presentation. So then there information, objects become more important and should be known explicitly in this case. Okay.

Hey, so I will then move forward. Yeah. On what it requires from it. I think there's an organizational integration. We hus just talked about what business has to provide with rights.

It, I think there's a very important pond and that's where, where many implementations of this concept riled with that. It, that say, let's say the, the business part, the part of business, which is not, it frequently has a relatively good description of their processes there and a lot of other things, but it itself doesn't have. So it is sort of, there are a lot of processes. There are processes for software developments of, for testing and other things for administration, for operations, which are defined the same way like this is are. But in fact, they are also business processes.

They need to be described, or at least be well known as business processes. They have functions, they have constraints and you have to do all it does the same way business does. Otherwise. You will always struggle with the civil land, with a lot of technical aspects around segregation of QDS and all these things. And that can be avoided if you describe to things and process. So it has to become, and to act has to become a part really of business and act like a part of business.

Also in that area, that's one of the fundamental problems we are observing that business is much better in doing this. And it is another thing is that it's it's lot of fitting to entitlements. So we need an exposure of systems, which fits to the entitlements defined by the business, which as I've said before, might require the redefinition of system level access control concept and their implementations. And what it also requires is what I would call an so D segregation of QT readiness. So the expos privilege, which we map to entitlements must not contain any OD conflict.

There have to be so D free conflict free. It's not allowed to have it there. And that's what we definitely have to do because the model handles the OD conflicts derive from the business view. And if we create artificial sod, conflict implementations at the system level, then we fail. So the segregation of duties, design quickly touches. And it's a, like the, the process will be a topic of another could call online training session webinar, where we didn't really focus on how to deal with segregation of duties. In some other aspect, they are managing the level functional roles.

Mainly they are derived top level from regulations, internal, external, and that from the business, and also for business whose internal regulations affect business rules and internal compliance constraints approach. So many compensatory controls can be implement using constraints. And ideally business rolls themselves. Those are free of SD conflicts and don't don't require additional compensatory controls. It might not work out every time, but in many cases we can do this.

In some cases you might deal with a little bit more complex things and, and look at their situations that might need a dynamic view on sods. But in many, many cases, that's really what we should do. And title ones have to be sod free.

Like I've said before, if there are SD issues and it systems, this is rate easier to fall, the management access controls in these, or the lack of, like I said, lack of implementing it processes like which then for example, describe in a software development process where the S O D conflicts potentially are between, for example, the test versus developers between people who have access to production environments and people who are developing things.

And if this is not implemented correctly at the business level, so it describing as part of it describes part of the business, then you will struggle. As, as I said before, this will be part of another session, which we will record soon and provide soon. But it goes beyond the time and scope we have within this webinar world hierarchy is another interesting point. I quickly wanna touch. You should avoid them to complexity. So the a model allows an unlimited level of role hierarchy. So every role could contain another role could contain a role. And so on.

We have some different levels of roles in our big picture, depending on how you implement, it might be two or three levels. Plus the entitlements post from the systems, any additional hierarchy leads massive increase in complexity. And there's no single known use case in which adding hierarchies really helps in reducing complexity. So rose can be described flat. The user is as generic growth for everyone. Then you have trust two assignments for the persons.

The employee has specific growth for all employees, but not the partners or the customers controllers a drop title with constraints and all these things it could be done. And it can be done. We've seen many projects works and trying to make things flat is much easier than trying to handle hierarchies. A technic outlook. We see the technology have to change. So the current status is that we have static access management has a common approach.

So we, we sort of administer access rights entitlements with some systems, and we do the manual manual mapping to entitlements and lower left level system access controls from the business roads and also today's access governance tools focus mainly on the gap between this desire and currency. One will become more important dynamic authorization management tools, which externalize the access management out of applications.

So the application asks a system at run time, whether this authorization is grant or not, and whether something approved or not at run time, they can then be based on factor roles, constraints in the context. So just bringing in these three concepts, avoiding even business roles can be done. It's far simple management, it's far simple in and is fully supported, covered by this concept.

However, this requires applications to support this concept related standards like, or maybe an upcoming restful API based successor to Xs. It's a massive investment for legacy apps. So it'll be a very long-term migration with lead both for, for a period of time.

But it's very clear if you look at our concept, it makes things easier when you move towards dynamic authorization management, because we support this, this concept, both approaches and in the dynamic world, well constructed systems, which externalize security in the especially authorization things become much easier than they are in today's system, world. One word around system level tools. So system level tools, which manage roles for a specific system or focus on the, for a specific system environment.

I think in a context of an approach, which, which starts at the business level, any system focused tool, even for the leading enterprise systems is inadequate. As long as it doesn't start with a complete business view, doesn't support the entire press it environment easier. You do it right as well on the management side and the it side, or you leave it. So I definitely think it makes sense. We have brought to a lot of information around enterprise role management, starting content. There will be other online prints. And then we be also additional research.

We have several pieces of which research which are relevant. In this context. We will also provide several reports around enterprise role management related topics in the near future. So have a look at this and you can access it. There's a 30 day free access, some limitations using our select program. And we have our chemical annual contracts for our customers to access all the new research, all the online trainings within this. So that's it from my side. Thank you for great attention. And thank you first for participating this. Thank you very Troy.

And hopefully you can improve your enterprise role management project. Thank you.