How to find roles

Not, many of you may have read this Blog post before here, posted at Sat. June 30^th to the GenericIAM Blog. Here I made the statement that "Roles are the organization". You may read through this short contribution before you go on listening to me.

And please always feel free to come up with a different opinion or with some critique as did one BLOG author - who unfortunately did not completely get the point.

Well, maybe I overstated my point there. More will be necessary to describe how an organization is expressed in roles.

What are roles?

When we talk about roles they are most commonly understood as functional roles. That means bundled corporate functions. So if you have a functional enterprise model (as opposed to an object oriented one) at hand, you may just select the appropriate functions, add them the functional role and give it a meaningful name. Yes, that's all.

Will it be enough to use these roles for granting access? Remember this is the idea behind Role Based Access Control (RBAC) after all. No, it will not.

But how do we get there? Ok, let's take a step back and consider the organization and all the objects around there and see what we can collect to finally have all determining information at had to define privileges.

What is the organization?

Figure 1: Roles link process to resources

Processes - Roles - Rules - they express the abstract Organization. They form a generic template not yet populated with real people and still without individual customers, contracts and obligations. So we are on the class level still - not yet their physical incarnation. As mentioned - it's the abstract organization.

So let's follow a top-down modelling approach:

• Business processes express the organization's dynamic behavior. Often they are the starting point. They are best understood and perceived as been the essence of the corporation - something to excel or to fail in.
  
• Processes themselves are made up of elementary actions which can be understood as some atomic activity - what one person does at a time in one location.
  
• These actions are performed by someone - not yet individual persons but on class level roles instead. So here they come into play - the roles, functional roles still.
  
• To be able to perform the singular actions these functional roles need appropriate access to resources. The functions are bound to resources. They are being "localized".
  
• Constraints drive this localization. They further restrict the roles access to certain subclasses in order to reflect the real world's needs. Those constraints express the privilege determining information dimensions like organizational unit, region, contract type, customer group and more. The resulting "business role" finally is the one which can be used for access control as it defines the intended privileges - still defined in business terms.

So processes and roles can't be modeled independently - without being incomplete. But only by taking constraints into account makes the model sufficiently determined to derive privileges for information object access from functional roles.
This picture to my opinion is more straight forward and easier to comprehend than the so called Stanford model:

Figure 2: Stanford model enterprise and system abstractions. McRae, R., The Stanford Model for Access Control Administration, Stanford, University, 2000 (unpublished but cited by Ferraiolo, D., and R. Kuhn).

Obviously role finding requires good and - even more important - explicitly documented knowledge of the business domain (best to be expressed in a formal enterprise model), some experience in related business modelling areas and a sound portion of intuition.

While existing, defined and documented business processes are an excellent starting point for successful role engineering, they still don't represent the most fundamental core objects of a corporation. Even more fundamental to an organization are the essential persistent (non-transient) objects:

The static IAM objects

The static IAM-Objects

Anchor point is the business role - ok, but let's start at the beginning - always a good idea. In this chapter I might reiterate ideas of earlier postings. However - as insight has progressed - my explanations may get a slightly different flavor than before. In case you feel bored just skip this chapter. But be warned - as virginal ideas are rare in general - you might encounter the usual suspects.

The identity	Identity: the digital identity is the digital representation of the individual, which has a defined relationship to the corporation. It is stored and maintained as long as the as long as the interest in this relationship lasts and no legal or regulatory requirements restrict its use.
The functional role	Functional role: a bundle made up of business functions as defined in a functional enterprise model which represents the tasks which have to be performed. So the functional role just specifies functions to be performed. The functional role can be understood as a projection to the enterprise model. In case the enterprise model is purely functional (in contrast to object oriented), the functional role just lists corporate functions. It doesn't contain any hints on how to grant access to information objects or applications. Even more; only in special cases you may be able to derive the affected information objects they are acting on from the role's names. Note: This applies if you have a functional enterprise model at hand. This is most commonly the case. Situation might look slightly different if there is an object oriented (means class based) enterprise model available.
The constraint	Constraint: constraints narrow the focus of a functional role. Well known examples are defined authorisation levels, to limit transactions by a maximum value (value authorisation) or to limit the scope of activity to certain organisational units or regions (structural authorisation). Value authorisations in turn can be further split into direct and indirect value authorisations. For example the permission to close contracts or to grant discounts up to a certain (direct) limit can be expressed as an amount of money. On the other hand there can be also maximum values defined for parameters (maximal validity period, or maximum mileage - both of a leasing contract) which can be converted to an amount of money after some form of transformation only (indirect). Furthermore it is rather common, that the contract type (employee, contractor, interim manager …) might lead to further restrictions of a role's full privileges. More types Constraints are possible of course and more discussion on this object is necessary I fear.
The permission	Permission: The elementary object of access management is the elementary privilege (permission). According to the RBAC standard it is defined as operation on objects. In case the privileges cannot be defined via access to information objects, privileges alternatively can be defined the access to systems.
The business role	Business role: In this model the business role is the central structuring element. It expresses all information necessary for the (technical) privilege assignment on business level. But you could also call it the localized Role.  By the introduction of the business role the purely functionally defined functional roles are finally bound to the specific Information objects (or alternatively systems). This can be done by linking directly to elementary permissions. (In some cases, when applications or systems offer some kind of roles already, the business role may link to these 'system roles'. But their introduction needs its own discussion) Here the constraints unfold their by definition restricting effect. If you manage to bind the information objects strictly rule driven to the functional roles you may not need to store the business roles. In this (lucky) case they can be considered as purely virtual (transient) objects. In most - real world - cases however we have to consider them as static (persistent) objects. You may imagine the business role as a triple of keys - and not much more. Those are the keys of the functional role it points to, the constraint, if there is any and finally the permission which is used.
The authorisation	Authorization: when the business role is assigned to a digital identity the object authorization is created. By this assignment the very act of the role based privilege assignment is done. In reality the identity is assigned several business roles to define the planned information object use. All access information is stored in one or more authorization objects per identity representing the total use of all relevant information objects. Note: In this context the object authorization is often called user. But  not the using person is meant but the relation expressing the use.

Processes of model maintenance

Those were the fundamental objects (again). But how to get the strange animals called roles now? Well, if you are asking for processes I finally have to deliver processes. Let's not forget: this is what GenericIAM is about, generic processes of the identity & access management.

So which processes do we need at first? Model maintenance means the maintenance of all of its objects. So we obviously may expect …

• Maintain functional role,
• Maintain constraint,
• Maintain permission and
• Maintain business role.

Maintain functional role:

Due to the high overlap with job descriptions, the functional roles can be considered as the natural starting point for a role based privilege assignment.

If requirements for separations of duties (SoD) are defined, functional roles are the appropriate object to check for violations as separations of duties are defined purely functionally as well. If the SoD conflicts cannot be resolved otherwise the implementation of mitigating actions (aka compensating controls) might become necessary. This SoD check becomes necessary when functional roles are either edited or combined.

The process of functional role maintenance is triggered by the initial creation of new tasks or change of existing ones, e.g. caused by changes of business processes. In these cases creations or changes of functional roles might become necessary.

Owner of this process should be some kind of business architect. To model functional roles he clarifies, which tasks within a business process are planned. By following along its elementary activities (what a person does at in one step at one location) he lists the functions according to the enterprise model that are necessary to run this activity.

If SoD obligations have to be met the resulting functional roles have to be checked for segregation of duties conflicts. If present such conflicts can be either removed by remodeling or their inherent risk be reduced by implementation of compensating controls.

Maintain constraint:

Constraints are used to further restrict the functions acquired via the assignment of a functional role. The definition of constraints is a risk mitigating measure, which can be implemented additionally or alternatively to other controls (four eyes principle, separation of duties …) to function as a "compensating control".
The process can be invoked by "maintain functional roles" as it narrows their focus. It should be owned by the above before mentioned business architect too.
The necessity for the definition of constraints is originated by business departments, risk management or - if appointed - a business architect. Together they determine the scope limitation or the maximum authorization level.

Maintain business role

As mentioned above in this model the business role is the central element of access management. By assigning a business role to a person's digital identity they are granted their privileges. This assignment is stored in the authorization object. The business role is therefore the static projection of the functional role to certain information objects while applying some constraints.

In a 1^st step a functional role is created as an empty container. It is given a meaningful name expressing the purpose of this role. Alternatively an existing functional role is selected from the enterprises pool of functional roles.

In a 2^nd step corporate functions taken from a functional enterprise model are assigned to the functional roles. Note: in order to comply with the principle of least privilege (PoLP) only a minimum set of corporate functions should be selected in this step. Obviously for this purpose the functional enterprise model needs to be sufficiently fine grained. If necessary at this stage you may want to change functional roles or create new ones (maintain functional role).

In a 3^rd step the constraints are applied to the business roles. This action obviously increases their number. A check for violations of segregation of duties requirements may be appropriate here as well.

In a 4^th step permissions are assigned to the business roles. Obviously here the respective Information owners need to get involved. Remember: Permissions are defined as operations on information objects. In cases where no information objects are defined but systems or applications in place instead you may need to consider permissions as 'operations on applications'. If necessary those permissions need to be changed or created (using the process "maintain permission").

The business role can still be understood on the business level. Not surprisingly we suggest the business architect again to be the appropriate owner. He will not be able to do this job alone. He might need the support of the information object owner / application or system architect.

Maintain permission:

What's about the permission? Doesn't it need to be maintained as well? Yes it does. However most often this is done in a different system: In the target systems rather than in a central AM system. While modeling these processes on the essential level however we need not to deal with these system boundaries.

Of course to decide which ones of the possible permissions to be exposed to the business oriented role modelers is a business decision. On the other hand only those permissions can be exposed, which are offered by the underlying systems. Clearly this is the domain of the information object owner / application or system architect.

Moreover in those cases where the underlying systems offer their own role models and especially in situations when roles on system level are in use by an implemented access management already application- or system roles can be squeezed in between the permission on the bottom level and the business role

in the center. As in the essential model there is no reason for the introduction of an application role, some extra discussion will be required in order to find a set of rules for crafting good application roles - but elsewhere.

Applying and granting

Those were just the (simple) processes of model maintenance. Perhaps I should provide an online tool prototype to demonstrate how it may work in reality. Still missing are the processes which lead to an assignment of roles to persons respectively their digital identities. Granting access to Information objects by assigning roles to individuals is not trivial as it more often than not involves some carefully crafted workflow. These processes are not yet covered here. They will follow in my next post. So please stay tuned.