Automated role concept according to basic characteristics and best practices

The Authorization Robot optimizes role concepts according to predefined criteria. These criteria must be modeled as calculable characteristics. Based on the mathematically optimized model, an authorization administrator can make customized adjustments to the Authorization Robot's proposed solutions that are not covered by the general quality criteria. Currently, the project is focusing on supporting the manual and time-consuming activities of analyzing the usage behavior, considering basic best practices when setting up roles, and even defining the authorization objects in the roles. The user can already design the role concepts according to basic characteristics, such as the reusability of roles, the overlapping of roles or the matching with user behavior (traces).

Manually customizing the role concepts of the Authorization Robot

More specific characteristics for industries, companies, areas or certain users are integrated into an existing role concept after the optimization. With the classification of authorization objects, a feature was implemented that supports a certain amount of this manual customizability. Before a role concept is calculated, the user can create an allowlist and a blocklist. All authorization objects of the blocklist are removed from the role concept. Authorization objects of the allowlist are systematically removed from all other roles and collected in an end-user role, which is assigned to all users usually. It should be noted that the Authorization Robot can design a role concept for an entire company as well as for a separated area. The allow- and blocklists can then be configured for this range of use. For example, an end user role for the finance area may look different than an end user role for the production area. In the simplest case, however, the default can be accepted. In this default there is a preselection of general and non-critical authorization objects. These are required regardless of the business unit.

In SAP, an authorization usually consists of three dimensions. There is an authorization object, up to ten authorization fields for each authorization object and various options for field value specifications (concrete values, ranges, wildcards) for the respective fields. From the combination of these dimensions, the user can map different use cases. In the figure, a blocklist was filled with three objects:

• In the first line, the authorization object S_DEVELOP is blocked regardless of its field value specifications. The user would now have the possibility to soften this rule by substituting ranges or concrete field values for the field values that were starred.
• In the second line, a combination of a field and a field value is blocked. Due to the star in the "Object" column, this rule applies independently of the object.
• In the third line, the field value specification "f4" is blocked. The combination of two stars makes this rule independent of an object and a field in which this value could appear.

Example blocklist with trhee entries

The structure of the allowlist works similarly. However, the Authorization Robot gives special consideration to programs (e.g., transactions (S_TCODE) and services (S_SERVICE)). When building the role from the authorizations of the allowlist, the SU24 is examined for each application. All required authorization objects are automatically loaded into the role. A comparison with the user behavior determines whether the respective authorizations are activated or deactivated.

Furthermore, the user has the possibility to specify fields of authorization objects uniformly in the entire role concept. A wildcard can be inserted as a field value for this process. The owners of the corresponding roles may execute the associated processes with this role in all possible variants. A supplied default is also available here, which has been compiled from the experience of numerous redesign projects by authorization consultants from SIVIS. For example, there are authorization fields that contain a file path or a specific document number. In these cases, the generous authorization in the form of a wildcard is useful to keep the role concept clear. In the first step, the user can select a field of an SAP authorization object. In the second step, he can decide whether this rule should be bound to the occurrence in a specific authorization object. This seems to make sense because an authorization field can occur in different authorization objects. In the figure, all fields are "starred" regardless of the associated authorization object because a star has been assigned in the "Value" column.

Example of starred fields with five entries