SAP Authorizations General considerations

Direkt zum Seiteninhalt
General considerations
Evaluate Permission Traces across Application Servers
If these issues are not taken into account during a conversion, there will be an imbalance between the system and the components to be protected, since the change in the system constellation means that new components, such as those mentioned above, must also be taken into account. Otherwise, a company may suffer economic damage and the resulting damage to its image. Furthermore, neglect of legal requirements (BDSG, DSGVO, GOB, HGB, etc.)1 can lead to legal measures or steps.

A major advantage of SAP SuccessFactors is flexibility. Different project teams can implement and use several modules, processes or add-ons in a short time. The processes can be optimized again and again. A central basis for extensively digitized processes are structured specifications that regulate system access and control access rights. In this context, SAP offers the concept of role-based authorizations. Role-based SAP authorizations grant different groups of people different options for action and views in the system, e.g., regulate access to salary data. Role-based authorizations are flexible and facilitate global implementations of SAP SuccessFactors, e.g. in different national companies. Once implemented, roles and their authorizations can be quickly rolled out to the new region. The roles do not have to be completely reconfigured each time. Slight adjustments are all that is required.
Essential authorizations and parameters in the SAP® environment
Do you also work in a complex system landscape where roles are decentralised? Then, inconsistencies can occur by transporting profiles from different systems to a target system. We'll show you how to prevent that. In the case of decentralised maintenance of eligibility roles, i.e. maintenance of roles in different systems or clients, there is a risk that the number sequences for the generation of eligibility profiles overlap. You can then generate profiles with the same name for different roles in different clients. As soon as you transport these eponymous permission profiles into a common target system, the profile will be overwritten by the newly imported profile and inconsistencies will arise. As a result, you may, for example, assign an ERP Permissions Role an SCM permission profile. This may result in a user assigned the ERP role not obtaining the required permissions or even too many permissions. You also have a problem if you want to use the permission profile to determine the source system and the client in which this profile was generated. This is not possible if the first and third characters of the SAP System ID (SID) and the number sequence for generating the permission profile match.

Which authorization data does a role have (PFCG)? Again, start the transaction PFCG and display a role. Then branch to the tab Authorizations and click on the button with the "glasses" (bottom left): Display authorization data.

During go-live, the assignment of necessary authorizations is particularly time-critical. The "Shortcut for SAP systems" application provides functions for this purpose, so that the go-live does not get bogged down because of missing authorizations.

At www.sap-corner.de you will also find a lot of useful information on the subject of SAP authorizations.

The following list may be supplemented by suggestions from the company's own administration.

What is the difference between transactions and how are they used correctly?
SAP Corner
Zurück zum Seiteninhalt