The goal of modern identity and access management systems (IAM systems for short) is not only to manage user management and its processes, but also to distribute and also remove the resources and permissions managed therein efficiently and in line with requirements. This is usually done using so-called roles, in which the necessary resources and permissions are grouped together. In most cases, the experience of who should be assigned which resources and who should also have them revoked is in the heads of the IT administrators and the business and system managers. And this knowledge is only called up when there is a change notification about a person or their new entry or exit. In many cases, there is also a time delay because “something more important has just come up”.
To counteract this situation and make it more uniform and faster, modern IAM systems offer functions to transfer this knowledge into a set of rules and to automate the processes described above.
The advantages of such a set of rules are obvious:
- The knowledge from the heads of the employees is documented in a set of rules
- The allocation/withdrawal of resources takes place automatically
- Every process is fully documented
- The elimination of recurring work frees up time and resources for other projects
- Rule-based resource management prevents uncontrolled growth and the accumulation of permissions and accesses.
But how does the set of rules actually work? Let’s take a closer look below.
Role is the Magic Word
Role, also called role profiles, are best compared with a role package or resource package. This is a compilation of IT resources (hardware, software, mailboxes, user accounts, …), permissions (directory access, access to third-party systems, …) and non-IT assets (keys, access cards, work clothes, tools, …) that belong to a logical unit or a role. These packages can then be assigned to the persons belonging to the logical unit.
Modern IAM systems, such as tenfold, extend this construct by automatically assigning and unassigning these roles/profiles to one or more persons. The associated set of rules is based on so-called field rules. The master data of each person is analyzed when a change is detected and the corresponding role (or profile) is assigned or revoked.
A new internal employee is assigned the role of development manager in Berlin.
The corresponding set of rules in this case would be as follows:
This so-called field rule exactly maps our example scenario and would then be assigned to the related profile for the role of development manager in Berlin. In this way, the IAM system would check each time a person is created or changed whether the person currently affected can have the required values in your master data.
If so, he or she would be assigned the role and thus also all the resources and permissions stored in the “package”.
In the other case, the role would either be ignored or revoked (if it was assigned once before).
With this example, we covered exactly one case that was very specific to the role of a development manager at a particular location.
Experience has shown that companies also have numerous “general” resources that are to be assigned to a larger group of people.
This is also not a problem for modern IAM systems, such as tenfold. You simply define the appropriate field rules and assign them to the corresponding roles/profiles.
In concrete terms, one follows a simple strategy:
But what does that mean exactly?
You build a corresponding role for each group of people that you know should always be assigned one or more resources or permissions.
- One role for ALL managed persons (internal employees, service providers, admin accounts, service accounts, …).
- One role for each type of person (internal employees, service providers, admin accounts, …)
- One role for each location (Berlin, Hamburg, Munich, …)
- One role for each department of each location (HR, IT, production, development, …)
- One role for each management position/role (head of department, team leader, senior physician, …)
Thus, there will inevitably be the effect that an employee in our example may be assigned up to 5 roles automatically. But this does not necessarily have to be wrong, as long as the summarized resources and permissions of the assigned roles reflect exactly what is required by the specifications and what corresponds to the experience of the specialist and system managers.
Experience also shows that changes to the role and resource assignments for the roles of the larger groups of people occur less frequently than for the smaller groups of people.
Very often, the goal of setting up roles or profiles is to map the organization chart of the company. This is a good basis for packaging resources and permissions.
IAM systems also frequently offer wizards to determine the common set of resources for a specific group of people. Combined with the experience of business and system managers, this makes it even easier to drive role creation.
However, creating and populating the roles is only one part. In order to work efficiently with the roles, a clean and detailed set of rules is required. We will take a closer look at how this can be built up in the following.
Download our Whitepaper!
In it, you will learn all the necessary steps to successfully implement an IAM system.
Field Rules - how to build them?
As we have already learned above, the set of rules, the automatic assignment is based on so-called field rules. These rules check the master data, which a person has, for each person change.
Now the question arises, how to build up these rules effectively, on the one hand to map your requirements and not to be overwhelmed by the amount of rules and on the other hand to get a flexibility in handling and using the field rules?
Let’s say up front that there is no golden rule for this and requirements may differ from environment to environment. Modern IAM systems, such as tenfold, are very flexible in this regard and are able to adapt to almost all circumstances.
At this point, we would like to look at the three most common variants for the structure and use of field rules.
This variant consists of storing all necessary checks of the master data in a single field rule. Referring to the above example, a rule would then look like this:
This allows you to assign this one specified rule to the associated role. This would look like this for the example of tenfold:
Short, single Rules
As an alternative, you can build many small rules that query only one master data type at a time. e.g. like this:
This creates flexibility in the use of rules in the roles. You don’t have to replace/expand the whole rule, as in the first variant, but only a part of it. The number of rules is also lower with this variant.
In a profile, the set of rules can then look as follows:
Are you looking for professional advice?
Do you need support with the introduction of an IAM system? Feel free to contact us!
The last variant for the construction of field rules is a combination of the two upper variants. One builds up to a certain master data level a combined rule and then supplements it with a smaller rule, e.g. like this:
Thus, you could map your department rules in detail and exactly and populate your department profile with them. The profile for the management level uses the same detailed department rule, but is extended and modified by a small rule for the position.
Which of the three variants is the best, everyone must decide for oneself and one’s requirements.
In summary, profiles are a good tool for automating recurring tasks, mapping roles, and assigning/withdrawing resources and permissions as needed and at the right time. This additionally relieves your IT, which can take care of administrative projects and tasks. The resulting set of rules also digitally maps the experiences of the business and system managers and thus finds a central place in the concept of user and resource management.