News

In the second part of the series, we talked about role management. We explained that a role is an abstract name for a group of permissions that, once approved, are assigned to a user. We learned about the role designer – the methodologist who is in charge of creating new roles. Today we continue with two more topics:

• Permission assignment options – is a role the only way to assign permissions to a user?
• Role mining – introducing an effective tool for when roles become overwhelming.

Permission allocation options

The ways to assign permissions to a user can be divided into

Direct assignment – the user is given permissions directly on the end system,
role-based assignment – permissions are assigned to the user indirectly by the role,
and attribute-based – a certain property of the user causes the user to get permissions.

Figure 1 – Methods of assigning authorisations

Directly assigned permissions

Direct assignment means that a resource (system account, card, system role) is assigned directly to a user. It is tied to their identity, and until a request is made to remove the permission, they are assigned it. This has negative implications, for example, when the user’s position changes. He gets new roles in the new position, but does not lose his old ones. Thus, he becomes a role collector who in a few years has access to every company system, whether he is entitled to it in his position or not.

Role-based access

Role-Based Access Control (RBAC) attempts to remedy the lack of direct assignment of permissions. This is a model in which users are assigned roles that only give them a certain level of access to a resource. The role assignment guarantees the user a certain access entitlement (so-called entitlement). Access is then assigned either automatically, or on the basis of a condition being met, or on the basis of approval by the responsible persons. RBAC is currently the most widely used method of assigning entitlements. However, when used consistently, it leads to the definition of tens of thousands of roles in larger companies, which differ, for example, by different combinations of user attributes. To improve the handling of such defined permissions, the ABAC model was invented.

Attribute-driven permissions

ABAC, or Attribute-Based Access Control, is attribute-based access to resources. For example: a programmer is working on a project to extract data from the company’s Data Warehouse. For allocation reasons, he is therefore assigned to the Datamining project in the internal project management system. This attribute is propagated to the Identity Manager. In IdM, the Data Warehouse system gestor sets that if the user’s project attribute contains a Datamining project, the user is allowed an account into the Data Warehouse system. In the same way, he can add other conditions, for example

• the environment information system attribute is equal to TEST,
• the current date is less than the expected end date of the project.

Role mining

When granting access based on roles, these roles are either directly entered into the Identity Manager or stored in a repository from which they are loaded into the Identity Management System. There can be more than one of these repositories; for example, Identity Manager can create roles based on so-called authorization objects (groups in Active Directory, SAP roles, nsroles in LDAP servers, and others).

With the increasing number of roles and the complexity of the infrastructure, the point is inevitably approaching when it is easier to create a new role in the system than to track down whether a role with the same scope of permissions exists. In this way, thousands or even hundreds of thousands of roles can be created in the role database over time, which are difficult or impossible to maintain. This results in hundreds of thousands to millions of assigned permissions, i.e. user-role relationships. This is where the practice of role mining comes in, which attempts to improve this situation.

Figure 2 – Condition before and after roll mining: Users, roles and accounts in the systems

If we want to get an idea of how effectively roles are designed, one option is to use a specialized tool to “mine” information from a database of roles and permissions. This allows analyses to be performed on the retrieved data using advanced algorithms. These analyses include:

• Clear views of the data, where the interrelationships between permissions – including hierarchy, and the relationship to users, including the temporal assignment of roles, can be effectively displayed.
• Finding users with the same or a similar set of permissions.
• Finding users who accumulate too many permissions.
• Finding unused permissions.
• Modeling new roles by so-called “refactoring” of existing roles.
• Comparing roles against each other to detect duplicates in composition (from the perspective of authorization objects, see above).

The following figure demonstrates a view of the analyzed data in the SAP environment.

Figure 3 – View of the data, from the left: Users, Roles, Author, Objects and Transactions

For example, built-in audit checks allow you to find roles that have the same or similar composition in terms of the authorization objects they contain. In the example below, 100% similarity is found between the roles for secretary and assistant. Therefore, they are probably duplicate roles. This example clearly shows the role of the role designer in the role mining process. The role of secretary also overlaps with the roles of car service manager and service specialist. Therefore, the output of the audit report only serves as a basis for the further work of this specialist.

Figure 4 – Finding the duplicites

Note: The “Score” column shows the similarity rate in %. Similarity is measured by the role’s binding to authorization objects.

After role management, we move on to the second topic of the article, which is the additional functionality that identity management can offer.

Advanced identity management features

The more specialized identity management functionality that we have not discussed in our series so far includes:

• License management – what if access to the information system is tied to a license?
• Role timeout – if we don’t want to forget to remove a role from someone.
• Delegation – or how to deal with a local administrator.
• Escalation – when users forget their tasks.
• Integration with Helpdesk – to work comfortably with Identity Manager.

License management

In some information systems, user access is conditional on the issuance of a license for the respective user. This license can be named per user or portable. As a rule, a portable license only specifies a limitation on the number of users (accounts) registered simultaneously in the system or service. The idea here is therefore to have an up-to-date overview of the number of users and to refuse any excessive requests for access until the number of licences is increased. This can be achieved by involving decision logic for license management in the approval of permission requests.

Example solution. has purchased an ERP system for core business management, the licensing agreement for which includes a maximum of 10 users on the system. Because this company already has an IdM solution in place, it has designated one staff member from purchasing as a License Manager, and added him as an additional step in the application approval process. From now on, whenever someone requests a role that has the attribute “License Manager approval required”, said employee will receive a task in the IdM system to review the request from a licensing perspective.

Figure 5 – Licence management in the context of the approval of role applications

Time-limited roles

More precisely, these are time-limited permissions implemented in the form of roles. This functionality is useful in those cases when it is necessary to limit the validity of the permissions assigned to a user from one side or the other. Whether it is access for a freelancer working on a project from-to-date, a new employee starting on a certain date, or a more complex example of a change in an employee’s assignment with limiting the validity of old roles to a certain date and assigning new roles effective from the date of the change.

Delegation

The principle of delegation is to assign a defined set of administrative tasks to a privileged user. This makes him/her an administrator for the area. These administrative tasks can be defined both in terms of functionality – for example, the right to reset passwords, the right to create users, the right to assign a role to a user – and in terms of scope – the right to manage users over a specific organisation.

Escalation

If everything in the process of approving user requests goes according to the prepared rules, it is clear who is responsible for what and when the task will be completed. But what if there is a situation where the approver is unscheduled indisposed, overloaded with work, or simply overlooks the informational email to review the request? In this case, escalation mechanisms need to be engaged. These allow to define rules on what should happen if the request is not decided within a specified time period. Options are for example: reminder email, referral to a superior, or automatic approval/denial of the request.

Integration with Helpdesk

An area that we are already making some inroads into the integration of IdM solutions with enterprise systems is the integration with the helpdesk system. The helpdesk system is the interface that corporate users encounter most often when they need something from someone. It contains ready-made templates for mundane tasks such as a request for office equipment, a request for leave, a request for IT support. So integrating permission requests into this system is a logical step that brings a consistent experience for users when making requests.

Conclusion

In part three, we explored the ways in which permissions can be assigned to users in the context of the management role and showed how to tame uncontrolled permission accumulation. Then, in part two, we looked at advanced identity management features. We went over license management, time-limited roles, delegation of privileged roles, escalation in permission management, and linking to the help desk system.

In the next installment, we will follow this up with areas related to identity management: access management as an active element of evaluating requests for access to systems, and SSH key management for better management of Linux users.

Author: Petr Gašparík