Authorization concept - user administration process
Bypass Excel-based Permissions Traps
In line with the maintenance of the SAP transaction permissions proposal values using the SU22 and SU24 transactions, it is advisable to maintain proposed values for web applications. In order for a user to be assigned a suitable rating for an operational feature set in the Web application, the software developers in the transaction SU22 must connect all the authorization objects required for this application to the corresponding Web Dynpro application, i.e. not just S_START. The source of the required authorization objects is usually a developer or permission trace.
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
The freeware Scribble Papers is a "note box" in which all kinds of data can be stored. It takes in typed texts as well as graphics and entire documents. The data is then organised in folders and pages.
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.
SAP Security Automation
However, there is also the situation that eligibility fields are collected at organisational levels. If these permission fields have already been filled with values in the PFCG roles, you must refill these organisation levels after categorising the permission fields as organisation levels. The PFCG_ORGFIELD_ROLES report helps you to do this, which matches all the roles with the organisation level fields, i.e. with the permission fields maintained in the organisation level fields.
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
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.
Normally, at least a 3-system landscape is used (development, test and production system).
This way I avoid that the user creates another authorization error when calling transaction SU53, which covers the original one.