A basic role combines almost all authorizations that all users need. It can be assigned automatically when a new user is created in the system, assigned directly, or included in composite or business roles, thus facilitating the rapid assignment of basic SAP authorizations.
A good authorization concept differentiates very strongly in the role structure. Each role then contains only the set of authorizations that is really necessary. This ensures that users only get the authorizations they need to perform their tasks. But there are transactions that all users need.
Building these into every single role would be costly and error-prone. You would have to touch and adjust every single role when you change these basic permissions. At the same time, you have to remember to include the full set of basic permissions every time you create a new role. This is difficult to implement in practice. Therefore, it is recommended to build a basic role that all users receive and in which all basic permissions are combined.
Which permissions belong in the basic role?
The basic role contains all the authorizations that every user needs. These can be system authorizations such as those for transaction SP02 (view own print jobs), but also authorizations for transactions that are used for error analysis such as SU53.
Important: The basic role never contains critical authorizations. Authorization objects such as S_DEVELOP or S_BTCH_XXX must not be installed in a basic role, or they must at least be restricted to pure display authorizations! They would permit otherwise the intervention into the system. Authorization objects and transactions that may allow access to sensitive data also have no place in the basic role.
The basic role alone is therefore not sufficient to make a user “workable”. It really only contains authorizations that EVERY user needs when working in the SAP system. Each organization defines the specific authorizations in its own authorization concept.
How is the basic role assigned to users?
Of course, you can create the basic role as a single role and assign it manually to each individual user in the traditional way using the PFCG or SU01. It goes without saying that this method is error-prone and extremely time-consuming. It is therefore at best recommended for very small systems with very few users and very little fluctuation.
In large systems, it would be quite tedious to manually assign the basic role to each new user. And it would lead to delays, because often you as an authorizer don’t even notice directly when new users come onto the system. Therefore, you need a way to assign the basic role automatically.
Assignment via GRC or IDM
If a GRC or IDM is in use, you can have the basic role assigned automatically whenever a new user is created in the system. Make sure that the role is excluded from the approval process so that it is assigned directly and not only after approval by the role owner and/or line manager.
If you work with Org Management, you can theoretically link the assignment of the basic role to positions. However, this is not very useful, because if ALL users should get this role, it is easier to link it directly to the users instead of to their positions. This is only useful for roles that should only be assigned to certain position holders – for example, roles that only buyers should have.
Assignment via composite or business roles
Instead of assigning the role directly as a single role, you can also include it in composite or business roles. In this case, it is advisable to include the basic role in every composite or business role that you have in use. This way, you can be sure that it is always assigned and not accidentally forgotten.
However, this method has a clear disadvantage: If you include the basic role in all composite or business roles and users are assigned multiple composite or business roles, this results in unnecessary multiple assignments. Although this does not cause any damage for the time being, it is not optimal in terms of data economy. In addition, every time you build a new composite or business role, you have to remember to include the base role.
Which method you choose ultimately depends on the following factors:
- how does the authorization concept provide for role assignment?
- is a GRC/IDM in place and can it be used for automated assignment?
- Does the authorization concept provide for business or collective roles, or do you work with single roles?
- how strict is the authorization concept with regard to the number of roles on the system/data economy?