Authorization concept of AS ABAP
Challenges in authorization management
First, create an overview of the customising tables currently available in your system. To do this, open the DD02L table and search for tables that start with Y, Z or your specific customer name space. Tables with delivery class C (such as customising, found in column A) are the relevant tables in this context. The descriptive texts to the tables can be found in the table DD02T.
Increased compliance requirements and the design of internal control systems confront companies with an increasing number of rules on how SAP (and other IT) systems must be technically protected. The SAP authorization concept specifies such legal standards and internal company rules. This ensures that each user only receives the authorizations he or she needs for his or her activities. The business risk can thus be reduced to a minimum.
Customising User and Permissions Management
SOS reports can be very comprehensive. In particular, if the Whitelists are not yet maintained, reporting volumes of up to 200 pages are not uncommon. Do not be discouraged in such a case, but start by cleaning up a manageable amount of critical SOS results. You can then edit the further results in several rounds. The AGS recommends which critical SOS results you should consider first; You can find these in the AGS Security Services Master slide set in the SAP Service Marketplace Media Library.
The authorization check for the authorization objects PS_RMPSORG and PS_RMPSOEH runs as follows following a user entry: The system determines the organizational unit to which the user is assigned. Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy. The system determines the set (M1) of all organizational objects that are assigned to these organizational units. The system determines the organizational unit to which the object to be processed is assigned (corresponds to the lead organizational unit in the attributes of the object to be processed). Starting from this lead organizational unit, the system creates a list of all organizational units that are superior to the determined organizational unit within the hierarchy. The system determines the set (M2) of all organizational objects assigned to these organizational units. The system forms the intersection (from M1 and M2) of the matching organizational objects of the user and the object to be processed. The system determines the organizational levels that match for the user and the object being processed. Once a matching organizational level is found, the system performs the authorization check for the other fields of the authorization object (e.g., type of object or activity); if the system cannot determine a common organizational level, processing is rejected. If the user is allowed to perform the requested activity, processing is allowed; otherwise, the system rejects processing.
However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".
After successful implementation of your permission check, the new authorization object for your application must be maintained in transaction SU24.
As the first graphic shows, our approach is built on a delta concept: all SAP authorizations and processes function independently of each other.