Role Mining

The primary motivation behind role mining is the simplification of role-based access control (RBAC). Users in organization are involved in many roles, organizational units and projects, requiring numerous permissions to carry out their activities. In an ideal RBAC system, each work responsibility, organizational unit assignment or project engagement would have its own role, a business role. Business role would group all the permissions necessary to carry out a specific business activity.

However, modeling business roles is no easy task. Business processes are often under-specified or even not specified at all. It is very difficult to find anyone in an organization that could tell which permissions are required for a specific activity. As business roles are very difficult to define from the bottom up, the common practice is to use application roles instead. Theoretically speaking, application roles represent user permissions in a specific application. Application roles are often the smallest pieces of permission data that identity management system works with. They are not supposed to be assigned to users directly. Unfortunately, it is a very common practice. However, such practice leads to numerous problems. The number of assignments is increasing, the access control model looks like a huge ball of mud in quite a short time. This makes the roles difficult to review and unassign, which leads to accumulation of security risk.

However, the processes are there and business activities are carried out every day. This means that the business-related permission information is there. It is just hidden, buried in the heap of access control data, waiting to be discovered. Role mining is a method to uncover such information. It uses algorithms and Artificial Intelligence (AI) techniques to sift through this maze of permissions, grouping them into cohesive business roles based on patterns of access.

Role mining detects candidates for new business roles based on data clustering, pattern recognition and similar methods. It suggests business roles that allow assigning similar permissions to groups of users. By conducting role mining, organizations can move from a chaotic, role permission model to a more organized, business role-based model. This transition not only enhances security by reducing the risk of access escalation but also makes the entire IAM process more understandable and manageable.

Role mining in midPoint is a flexible process that usually includes several steps:

Role mining is carried out in sessions. Each role analysis session is a data structure that contains setting for a particular case of role mining. When role mining session is set up and launched, the role mining process is started. Role mining is detecting clusters, groups of similar permissions (application roles) and users. Each cluster is likely to contain a business role suggestion. Both session and clusters are represented by midPoint objects:

Before starting role mining, it is important to collect all relevant data. This basic step sets the stage for the entire process. Extract the current access rights detailing which users have permissions and access to which. Collect information that can provide overview of access needs and patterns.

Once data is collected, it needs to be analyzed to identify patterns and inform the creation of potential business roles. Identify recurring access patterns across different users. Use algorithms to group users with similar access patterns. These clusters hint at potential roles. Detect any unusual or outlier access patterns that might signify misconfigurations or excessive permissions.

We use a density cluster approach that helps group users or roles that act similarly. Density-based clustering is a category of clustering algorithms that partition data points into clusters based on the density of data points in the feature space. The core idea behind these algorithms is that a cluster in the data is a dense region of points that is separated from other dense regions by areas with low density of points.

In our case, we cluster the data with respect to the chosen mode of analysis:

To start the clustering process, we need to define additional rules. These rules are part of Session clustering procedure options:

After successful clustering, we created groups of similar objects, or clusters. These objects are ready for further analysis from the point of view of finding patterns (groups of objects with exact overlap). To maintain the hierarchy and security of access rights, we focus on the exact overlap match. With such an approach, we avoid noise or similar inconsistencies when designing a pattern, and we will ensure that no new unwanted rights are added.

Clustering data are further analyzed using pattern detection algorithm. Results of a pattern detection can be used as business role candidates.

Pattern detection options:

Pattern detection takes place automatically after the clustering procedure, except for the Process Mode (SKIP) setting in experimental.

After data clustering and pattern detection steps, we have almost everything generated, except for the missing statistical data. They are important in facilitating the management role of the mining process. They play an important role in the selection of suitable clusters on which to search or build a business role. We process the following statistical data:

After these steps we have a complete session. Based on the analysis, begin to define potential business roles that represent a common approach patterns. We simply go through the list of detected patterns and select the most suitable one. If necessary, the structure of the proposed pattern can be fine-tuned by assigning additional rights and users falling under a specific cluster.

In case of not finding or finding inappropriate patterns, the detection can be started again directly above the cluster with new customized detection options.

After roles are defined and refined, it’s time to integrate them into the business role access management structure. The last step of role mining is migration to a business role. In this step, we can set business role additional parameters belonging to the role category, such as adding access rights and candidates who should have the newly created business role and run a task that applies (migrates) the new business role to the selected candidates.