SAP Authorizations - Overview HCM Authorization Concepts
What to do when the auditor comes - Part 1: Processes and documentation
The Security Audit Log can also log customer-specific events in restricted way starting with SAP NetWeaver 7.31. The event definitions DUX, DUY and DUZ are reserved for customers and delivered with a dummy expression. For these events, you can then define individually configurable messages using the RSAU_WRITE_CUSTOMER_EVTS function block. To do this, you must first identify the additional necessary events and define their message texts and variables. Note that you may not change the meaning of the message and the arrangement of the variables later, as this would prevent older log files from being readable. Finally, you must include the new message definitions in your filters (transaction SM19). You will find the corrections and an overview of the required support packages in SAP Note 1941526. Since the use of this functionality requires extensive knowledge about the Security Audit Log, it is important that you also consider the recommendations in SAP Note 1941568 and that you can be supported by a basic consultant.
To access business objects or execute SAP transactions, a user needs appropriate authorizations, since business objects or transactions are protected by authorization objects with multiple authorization fields. Authorizations represent instances of generic authorization objects and are defined depending on the employee's activity and responsibilities. The authorizations are combined in an authorization profile (Generated profile), which is assigned to a role. User administrators then assign the appropriate roles (single role or composite role) via the user master record so that the user can use the appropriate transactions for his or her tasks.
Identify Executable Transaction Codes
In a redesign, we follow the principle of job-related workstation roles to technically map the job profile of the employees. To minimize the effort for the same job profiles with different organizational affiliations, the organizational units are inherited via an additional role. The separation of technical and organizational requirements greatly simplifies role development and modification. If certain people, such as team leaders, require extended authorizations, key user roles are developed for them, which extend the existing job role.
For a long time, SAP authorization consultants and ABAP developers have disagreed on how to implement authorization object characteristics in the coding. There are two positions: On the one hand, consultants advise never to test for the signal word DUMMY, the constant space or the literal ' '. These tests only superficially check for the existence of an authorization object and do not react to settings in the field specification in the profile of the roles. Moreover, the literal ' ' is then authorized because it is displayed in the transaction STAUTHTRACE. On the other hand, there are situations where development uses these superficial tests to save the user time and the machine resources. If the program determines early on that the user does not have the necessary objects in the user buffer, it may abort before the first SELECT and issue an appropriate error message. Both positions contain a kernel of truth. Let's look at the effects of different programming on a simplified example. The role(s) have only the authorization object S_DEVELOP with the field value DEVCLASS "Z*".
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
However, we recommend granting permissions at the function block level, because function groups often contain a large number of function blocks and the accessibility is expanded unnecessarily.
This makes the structural authorizations very flexible.