Activity level
General authorizations
Different organisational fields are used in each module. Since there are many interfaces between the modules, the main organisational fields of the modules must be linked. However, there are also organisational fields that are only relevant for the respective module. All object fields used as organisational units are listed in the USORG table. You can call this table through the SE16 transaction. Alternatively, in the selection screen of the AGR_1252 table, the value help of the VARBL field also shows the corresponding name for the respective organisation fields.
For an authorization concept, a clear goal must first be defined that is to be achieved with the help of the concept. This should list which regulatory requirements the respective SAP system must fulfill and the associated authorization concept must take into account. In this way, the legal framework conditions are defined. In addition, uniform naming conventions should be used because, on the one hand, many things cannot be changed after the initial naming and, on the other hand, this ensures searchability in the SAP system. Clearly defined responsibilities ensure the effectiveness of a concept. Specific persons must be named or at least roles defined in a separate section. A chapter should be dedicated to the process for user management. Here, it must be described how users obtain existing SAP authorizations, how new users are integrated into the SAP system, and who is responsible for approving authorizations. The chapter on the process for authorization management defines who is allowed to create and edit which roles and who is responsible for the development of various related processes. The chapter on special authorizations describes processes and special features in the area of non-dialog operations. These include job management and interface convention. Other administrative authorizations can also be described. The chapter on role concept explains how business requirements are transferred to a technical role. The role concept takes on a special significance, since it describes the actual mapping of business roles to the technical roles and thus to the authorizations in SAP.
Structural authorizations
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.
You must enable a role that you have created as a Design-Time object in the Design Time Repository before it can be associated with a user. To do this, use Project Explorer to select the role you want to enable and select Team > Activate from the shortcut menu. This will create a runtime object of this selected SAP HANA role. This object is also understood as a catalogue object and is incorporated in the Roles branch in the corresponding SAP HANA system.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
The SPTH table allows you to protect the file system from ABAP programme accesses without granting permissions and to deliberately define exceptions.
No matter what the reason, it is quickly said that a new authorization concept is needed.