SAP Roles and Profiles | What is a Role and a Profile?

Understanding how roles and profiles work within SAP ERP

At Xamai, we want to talk about roles and profiles in SAP, which are terms that are often used incorrectly because they are not synonyms. Today we are going to explain in detail what a role and a profile are and all the elements corresponding to them so that you have a full understanding of their function.

What are the roles and profiles of SAP?

To better understand what they are, we need to talk a little about the early versions of the SAP system, because at that time there were no roles, only profiles. 

Profiles refer to the elements that allow you to assign authorizations to the users who use the SAP system. Through them, it is possible to enable users to use the system. 

The concept of role has been introduced more recently than that of profile or authorization profile.
But let's try to give a definition and then develop it:

A profile is a container of authorizations and a role is a container that is made up of three parts: menu, authorizations, and user assignment. Perhaps this is still not entirely clear.

We said that before, to assign authorizations to users, only profiles existed. That is true. For a user to be able to execute, for example, a purchase request or an order, it was necessary to identify all the authorization objects required for these aspects of the process to function. 

All these objects had to be placed precisely in a profile and that profile had to then be assigned to the user or users.

This was very laborious and time-consuming, especially because there are more than 3,000 authorization objects defined in an SAP system. The process was carried out by trial and error.

 Roles, therefore, have the ability to simplify SAP authorization management, thus introducing RBAC (Role Based Access Control) or role-based access control.

 How is this process carried out?

Previously, through profiles, the security officer had to know all the objects to be enabled; today, through roles, it is possible to assign the transaction that a person will have.

This means that the role (through the PFCG transaction - Profile Generator) will allow you to retrieve all the necessary information (from an authorization point of view) so that the user, once the role is assigned, can work.

Profiles and roles should not be used together. Therefore, profiles are a legacy of the past (still active in the system) but "hidden" through role management. Therefore, they should not be used. Only roles should be used!

 

Do SAP roles facilitate authorization management?

Yes. Although it depends on how you structure them. In the SAP authorization environment, it is really like that: anyone can make things work easily by trying to define an authorization concept.

But one thing is to make them work and another very different thing is to make them work as they should and, above all, to manage them properly over time.

It is common, in fact, to find situations of authorization models defined at the beginning of the project and then overlapped, modified without much logic by several hands over time, to the point where you have to review everything.

What happens when you have access to roles and profile administrator?

Roles and authorizations allow users to securely access SAP Standard and customized transactions for the company.

There are no risks because SAP provides a defined set of standard generic roles for different modules and different scenarios depending on what happens in the company.

We can also define roles based on the project scenario taking the following into account:

There are two types of roles:

Master roles: with transactions, authorization objects, and with all management at the organizational level.

Derived roles: with management at the organizational level and transaction and authorization objects copied from the master role.

Components of a Role

A master role or a derived role has the following components within it:

• Transaction Codes
• Profile
• Authorization Objects
• Organizational Level

Transaction Codes

Transaction codes (T-Codes) are commands that allow quick access to different functionalities within the SAP system. A role contains the T-Codes that the user will be able to execute, thus defining the transactions they are authorized to use.

Profiles

A profile is a structure that groups the authorizations of a role. Each role has an associated profile that collects the user's access definitions. These profiles are created automatically when roles are generated, and are the ones that are actually assigned to users to grant permissions.

Authorization Objects

Authorization objects are the elements that define what specific data a user can access or modify when performing a transaction. These objects allow for detailed control over which operations can be executed within a transaction, including restrictions by type of activity or level of information that can be viewed.

Organizational Level

 The organizational level refers to the organizational structures that limit authorizations within a role. For example, a role can restrict authorizations to a specific company, a plant, or an organizational unit. This ensures that access to information and transactions is limited to certain parts of the organization.

Differences between Master Roles and Derived Roles

Master roles: maintains all transaction codes and related authorization objects. A master role is a role that serves as a template or base role for creating derived roles. It contains a predefined set of authorizations and permissions that are common to a particular group of users or business processes within the organization.

Derived RolesThese roles are basically derived from the master role, which contains only organizational values and is assigned to the user. It inherits the authorizations and permissions from the main or principal role and may also have additional authorizations specific to the organizational unit.

Assigning all organizational access to the same user is not an adequate security practice. Users are only allowed to have access to a specific organizational level according to their location and responsibilities.

Therefore, with the Master and Derived roles approach we can provide access to a specific organizational level to users.

The role of the functional consultant in role and authorization management

The BASIS team has knowledge about user management, role creation, profile creation, role and profile assignment, authorization assignments, etc., but the main concern in most cases arises when the BASIS team does not answer the following questions:

1. Who should roles or transactions be assigned to?
2. What and to whom should a transaction be restricted?
3. How to authorize custom transactions?

This type of question cannot be answered by the BASIS team. In this case, the role of a functional consultant comes into play, who is responsible for guiding them through the exact organizational structure so that there is no room for doubt.

To make it easier to understand, we will give you a small example: let's suppose we have a maintenance team with the following organizational structure:

1. Supervisor: Is responsible for reporting breakdowns or corrective maintenance requirements.
2. Maintenance Supervisor: is responsible for assigning the previous tasks to the engineers.
3. Head of Department: Is responsible for approving maintenance tasks.

In this case, the Functional Consultant is very aware that the Supervisor would only require transactions related to Notifications (e.g., IW21, IW22, IW28, IW29, etc.), the Maintenance Supervisor would require some of the transactions related to notifications (e.g., IW22, IW28, IW29) and also transactions related to orders (IW31, IW32, IW38, IW39, etc.) and the Head of Department would require notifications and order transactions (e.g., IW28, IW29, IW38, IW39) and also, along with this, would require special permissions such as releasing orders, approving permits, etc.

From the perspective of the BASIS team, they do not have a clear understanding of these requirements and, therefore, cannot make a decision on them and must be provided by functional consultants.

But, the main problem in most cases arises when functional consultants do not know the concept of roles and authorizations, so it is necessary that this information is fully mastered.

Xamai your best ally

At Xamai, we help you gain a better understanding and optimization of your SAP roles and profiles. Since roles simplify access management through Role-Based Access Control (RBAC), we help you with the correct implementation of these roles and the organization of user access, ensuring that operations flow securely and efficiently.

Furthermore, we can guide you in the creation and administration of master and derived roles, allowing us to help you structure your authorizations according to your organizational levels and specific requirements.

In this way, at Xamai we not only help to efficiently manage access, but we can also collaborate in training the BASIS team and functional consultants, to avoid errors and guarantee a coherent and secure administration of authorizations in the long term.