Roles – What we mean by the term
According to a definition published by the NIST [1] a role is a job function or employment position to which people or other system entities may be assigned or a set of named duties or job functions within an organization.
This definition clearly represents a business view. It is therefore a natural approach to define roles in business terms first. Hence the resulting business roles are to be owned by those, who own the business itself.
A more technical perspective leads to the definition: A role is a collection of permissions in role-based access control, usually associated with a role or position within an organization.
Hereby permissions are understood as operations on objects. By objects in the context of information technology information objects are meant, as ultimately it is the information, the access to which needs to be controlled. Systems are needed only as a means only to achieve that goal.
In order to use executable business roles in automated processes, in the end the business view and the technical view needs to be combined in the responsibility of the business role owner.
How to design roles
1. Start with the information objects
The most common justification for access control is to protect sensitive corporate information like e.g., products, customers or contracts against unsolicited disclosure or manipulation. Hence in these cases the Information sensitivity class or information protection class determines the measures to be taken.
2. Name the operations
Information objects are to be protected by blocking or restricting access to them. There are the basic maintenance operations like create, read update and delete (CRUD) and operations shaped by a business intent, like authorize up to a certain amount or close contracts with a certain customer group. These are the most basic business functions to be authorized. These operations on objects are also known as permissions.
3. Order the operations in a functional taxonomy
All permanent business functions are to be ordered in hierarchical enterprise model, usually called functional taxonomy or domain model. The functional taxonomy not only serves as the foundation for access control but may in addition be used for fine grained cost controlling or serve as a basis for a digital twin of the corporation.
4. Package business functions to functional roles
Business functions in the functional taxonomy may be referenced to be assembled to functional roles according to documented job descriptions and / or common (good) practices used in operation. In case functional roles have to be created from scratch, basic activities taken out of business processes are a good starter, provided represent an elementary session (one person, one time & one location).
5. Form business roles by constraining functional roles by constraints
Functional Roles form the basic element of Role Based Access Control (RBAC) as defined by the NIST. For practical use however they need to be further narrowed in by applying one or more constraints as they offer too broad a range. Typical static constraints are location, hierarchical level, organisational unit, contract type, sales region, product family or customer group. There may be more static constraints as well as dynamic one, which use to change over time, like device, time of the day, location of access (via mobile devices) or work status (in temporary leave or not). The resulting roles represent the central object of role based access control and are called business roles. Up to here all tasks are defined in business terms and should be carried out by business people. No IT skills are required so far.
6. Identify the systems, enabling the operations on objects
As information objects are rarely manipulated directly but rather via systems, access control is done via these systems. But first the relevant information objects need to be linked to the systems which enable disclosure or manipulation. To do this sufficient system knowledge is required.
7. Subdivide the business roles to system roles
Once the supporting systems are identified, they can be selected per business role. If there is more than one system supporting the business role, it can be split by system into system roles, otherwise business role and system role will collapse, meaning they are simple identical. Often systems contain their own pre-built role model, which need to be linked to business role in a bottom-up process. In these cases, it is not guaranteed that a complete match of the business functions assembled and constrained in the business role will completely match the functions offered by the pre-build system roles. Creating system roles requires a joint effort of business people and technical staff.
8. Link the business functions to technical functions
If not already done by assigning pre-built system roles in the previous step, now the business functions need to be assigned to technical functions, offered by the system. And this has to be done system by system, resulting in a complete implementation of the business roles’ business functions as technical functions. Obviously this task is to be performed jointly by business people and technical staff as well.
What types of roles will exist?
As mentioned in the role design process there are 3 major types of roles:
- Functional roles,
- Business roles and
- System roles
Functional roles are just a bundle of corporate functions.
Business roles are functional roles further narrowed in by applying constraints of different dimensions.
System Roles are business roles reduced to that part, which applies to just one system.
You might come across more seemingly different role types, which however can be reduced to the existing ones. E.g. organisational roles are business roles with always the same very general function, (e.g. employee, or member) but the two constraints organisational unit and location are varied.
How to maintain a high role quality
The entire role model of an enterprise needs to have assigned a responsible owner.
It is in his responsibility to …
- Scan for redundancies, detect, discuss and eventually remove them.
- Define health metrics for the role model and keep records of their status.
- Check for adherence to the naming conventions
- Check, if by an improved role-model security breaches, SoD violations, SoD exceptions or business complaints could have been avoided
- Report the status of the role model on a regular basis.
Who is responsible for roles?
Next to the role model owner, there are role owners, who hare typically responsible not just for a single role but for a bunch of roles.
For functional roles and business roles the role owners need to be business people.
For system roles the owners will be located most probably within information technology (IT).
For linking the business view on the roles with the technically offered functionality role owners of both sides need to meet in regular sessions or on demand.
What other processes are associated with role modelling?
Generally, there are three layers of processes, as with all business there are operation, managerial and governance processes …
1. Operational processes
Assumed a common static role model is in use the typical operational processes are assigning and revoking roles. For the regular standardised business jobs these processes should run in a fully automated way.
Only the assignment of additional role, which are not part of the pre-defined job descriptions need to be assigned via a request and approval process.
2. Managerial processes
The managerial layer encompasses all role maintenance processes including those mentioned in the chapter “How to design roles”.
Special care however has to be applied to role change and role deletion.
As long as roles are in use any change may cause unwanted side effects. The involved risks may be reduced, if a role versioning is supported, so that the old version of a role, which is subject to change, may stay unaffected and only new role assignments benefit from the actual role content.
A deletion of roles is only appropriate once no references to the role exist any longer, i.e. they are no longer in use.
3. Governance processes
As governance is defined as “direction & oversight”, the mostly informal processes regarding role strategy are located here as well as all audit, re-certification, expiration and quality management processes, like the above-mentioned processes to maintain a high role quality.
[1] National Institute of Standards and Technology – NIST , https://csrc.nist.gov/glossary/term/role
