In this article, we would like to offer a basic introduction to SAP authorizations, as it is important to have control over them. Additionally, we will provide a brief explanation of the most relevant concepts. Below, we will attempt to answer these and other questions.
The basic principle of authorizations is that they allow a user to perform a series of specific tasks in a SAP system, whether it is making changes, viewing information, or carrying out any type of management.
The first thing to keep in mind is that, to perform activities in a SAP system, you need an account in the system and, therefore, a SAP user. This user will be assigned a SAP ID, which will be the employee’s identifier in the system. Authorizations are not assigned directly to a SAP user but are included within a role. A role is basically a container where transactions and authorization objects (which we will discuss later) are included, and these are what grant access to users.
Depending on the role model a company has, authorizations will be distributed across different roles, so a user may have more than one role assigned.
It is important to have a good configuration and restriction of authorizations assigned to users, as improper access can cause a user to make unauthorized changes in the system or view data (such as other employees’ payrolls) that do not correspond to their position or rank, whether by forgetfulness, omission, or malice. In case of doubt, it is always advisable to consult professionals who can assist with the configuration of authorizations and user roles.
On the other hand, having a well-configured role model will allow the company to reduce the costs of maintaining and assigning authorizations to users, as well as resolving incidents or changes. This model should be able to assign users only the access they need, no more, no less, thereby reducing the number of risks and avoiding the assignment of improper critical access.
Basic Concepts
We have already discussed what authorizations are and that they are assigned to users through roles, but how are authorizations configured and how can they be restricted?
Transactions
As mentioned in the previous section, roles include transactions and authorization objects. Transactions are shortcuts to programs that execute specific actions and usually have a nomenclature that helps identify their functional area. For example, transactions that start with “F”, like FI01, are related to Finance, while MM01 is related to Material Management. The exception is customized transactions, which must always start with “Z” or “Y”.
Authorization Objects
On the other hand, there are authorization objects, which are tools to restrict transactions in a simple and quick manner. The main restrictions are by activity and organizational section, meaning access can be restricted to viewing only or to a specific area of the organization. Within each authorization object, there are classes or fields where the necessary restrictions can be applied, as not all transactions have all types of restrictions; some only allow restrictions on the objects they are associated with. Although the most common restrictions are those already mentioned, there are many others, such as by document type, material type, HR infotype, etc.
These are the basic cases for an R3 system. For other systems like Fiori or BPC, other types of items can be added to the role, such as catalogs and groups for Fiori or queries, among others.
Authorization Buffer
A very relevant point in authorizations is the user buffer. It is a temporary container of the user’s authorizations, meaning the objects and field values of a SAP user, regardless of the role they are included in. This way, when the system checks a user’s access, it does so through the buffer, verifying all the necessary accesses for the tasks the user is performing. It is also an efficient way to see all the authorization objects and their restrictions for a user without having to enter each of their roles to review multiple information tables. This buffer is available in transaction SU56.
It is important to emphasize that SAP relies on this buffer to check the user’s access, where all objects and transactions are combined, regardless of the role they are assigned through. Therefore, if a user has an object in two roles (one restricted to viewing and another unrestricted), SAP will always use the broader one. Thus, even if a user has a transaction in a role restricted to viewing only, if the object that allows changes with that transaction is in another role of the user, they will be able to make modifications.
Conclusions
Users in SAP use authorizations to perform their daily tasks, which are assigned through roles. A role includes transactions (access to the program to perform the task) and authorization objects (elements that serve to restrict parts of the transaction, such as activity or the part of the organization the user can work on).
It is very important to have control over user authorizations, following the principle that users should have only the necessary and sufficient access for their work, no more, no less. Not only because this makes the system easier, more controllable, and economical to manage, but also because security will be better controlled and there will be fewer chances of fraud. In this regard, good access management significantly contributes to the daily management of the system and its users.