Technically, the creation of authorizations in SAP systems is a relatively simple operation. If you know to which transactions/programs the authorizations are to be assigned and what restrictions should be made, the creation of an appropriate role does not seem complicated. However, the picture becomes less clear when you look at the authorizations from the perspective of the whole system.

In functionally complex systems, like SAP solutions, the key is to design the grid of authorizations in such a way so as to enable them to be clearly assigned to the appropriate job positions (users). The challenge is to group authorizations in roles in such a way so as to allow them to be reused multiple times, while taking into account the fact that the authorizations of individual users are often slightly different (which complicates grouping).

For example, all employees working as personnel administration specialists use the same set of roles, and additionally, for a selected employee, the authorizations can be extended to cover the functionality of managing working time or the company social benefits fund.

In the whole process, an approach to later changes of authorizations (creation of new roles or modification of existing roles) is also very important. As a result of frequent changes of authorizations, often on an ad hoc basis, made in isolation from the initial concept, after a few years of use you find out that users have much broader authorizations than they should have. In addition, due to the changes made, the definition of specific roles gets blurry. This results in, for example, multiple conflicts when you introduce the SoD (Segregation of Duties) rules and increases the risk of unauthorized access to data.

Below we present the basic rules that should be taken into consideration when creating or reorganizing authorizations in SAP systems.

An analysis of activity

The first and most important step in creating or reorganizing authorizations is to collect complete information on user activity in the system. The information what transactions, programs are used at a specific position, what restrictions are applicable (e.g. a company code, a sales channel, etc.) is essential.

Such information should be placed e.g. in the documentation of business processes. If you fear that your documentation is not complete and up to date, you can collect such information from key users.

Tools for collecting information about user activity can be also useful. They include:

  • ST01 – System Trace,
  • SM20 – Security Audit Log.

A security log fragment for the BCCBASIS user

Finally, you should get a sheet that describes the activity of all users at individual job positions. Due to the large amount of information, sheets should be divided, for example, by modules (one sheet per each module).

A sample section of the activity/authorizations sheet

Grouping of authorizations into roles

After gathering complete information about user activity from a particular module, you can start grouping authorizations into roles. If you have a well-prepared sheet, it is relatively simple. You can visually assess which transactions can be gathered in one role so that it can be used for several job positions.

Grouping of transactions into roles

As you can see, in the example above it is sufficient to create three roles. Of course, the situation is not always so clear; it may happen that certain positions will require access to individual transactions and then you will have to create more “minor" roles.

At this stage, you should create roles as single roles. Alternatively, you may also use derived roles in a situation when, for example, you have the same activities (transactions/programs) at several job positions, and the differences lie in restrictions e.g. other company codes. The use of derived roles will allow you to modify roles more easily in the future.

In the next step you describe your roles in such a way so as to enable them to be easily created in the system. Since a single role can contain dozens of authorization objects, it is recommended to make an assumption that only the information that is necessary to create a role should be placed in the sheet. You ignore the authorization objects that you are not filling in (they have default values), as well as those that have full authorizations (*). All objects that have no value, and those that you are modifying (changing the default value) should be in the sheet.

Thus prepared, the sheet will enable individual roles to be created in the system by a person who is not involved in the project of creating authorizations.

A sheet of roles

Assignment of authorizations to users

It is most recommended to group the prepared individual roles into complex roles. This approach definitely makes it easier to assign authorizations to users.

We recommend that one complex role correspond to a job position. In this way, the assignment of authorizations to a user requires only one role to be assigned (individual roles will be assigned indirectly through the complex role).

A section of a sheet of complex roles

Segregation of duties

When creating authorizations, you should remember to perform the segregation of duties. Having prepared the appropriate matrices of conflicts, you can – as early as at the activity analysis stage – check whether the activities assigned to the job position interfere with one another.

Once you have created roles in the SAP system, you can automate the process of checking for SoD conflicts using additional tools, such as SAP GRC or third-party tools, or make use of the solutions that are available in the system, such as an analysis of critical combinations (report RSUSR008_009_NEW).

Unfortunately, the preparation of appropriate definitions of critical authorizations, and then grouping them into combinations corresponding to the conflicts requires a lot of effort.

What should be kept in mind

When carrying out the project of reorganization or creation of authorizations, a few basic principles should be kept in mind.

To be able to properly design roles, you are required to have knowledge of a given SAP area/module, therefore it is recommended to engage in the project the persons who know the specific features of a given area (e.g. key users or module consultants).

If the roles were not well-designed, the sum of authorizations of several roles may provide the user with a broader access than planned originally.

The newly created roles should be tested. As a test scenario, you can use the activity sheet.

In case of problems, it is recommended to use for the analysis a set of reports available in the SUIM transaction. They can be used to look for specific information (roles, users, assignments, etc.) as well as to track the changes made in the authorizations with the help of change documents.

The created roles should have consistent, legible names so that you can easily identify them and determine what they refer to.

If you are dealing with systems where multiple clients were identified, then you might consider configuring the central user administration (CUA) to improve the assignment of authorizations to users (you can configure it centrally at a single point, instead of doing it on each client separately).