Authorization Checks
To ensure that a user has the appropriate authorizations when he or she performs an action, users are subject to authorization checks.
The following actions are subject to authorization checks that are performed before the start of a program or table maintenance and which the SAP applications cannot avoid:
• Starting SAP transactions (authorization object S_TCODE)
• Starting reports (authorization object S_PROGRAM)
• Calling RFC function modules (authorization object S_RFC)
• Table maintenance with generic tools (S_TABU_DIS)
Checking at Program Level with AUTHORITY-CHECK
Applications use the ABAP statement AUTHORITY-CHECK, which is inserted in the source code of the program, to check whether users have the appropriate authorization and whether these authorizations are suitably defined; that is, whether the user administrator has assigned the values required for the fields by the programmer. In this way, you can also protect transactions that are called indirectly by other programs.
AUTHORITY-CHECK searches profiles specified in the user master record to see whether the user has authorization for the authorization object specified in the AUTHORITY-CHECK. If one of the authorizations found matches the required values, the check is successful.
Starting SAP Transactions
When a user starts a transaction, the system performs the following checks:
• The system checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.
• The system then checks whether the user has authorization to start the transaction.
The SAP system performs the authorization checks every time a user starts a transaction from the menu or by entering a command. Indirectly called transactions are not included in this authorization check. For more complex transactions, which call other transactions, there are additional authorization checks.
The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization with a value for the selected transaction code.
If an additional authorization is entered using transaction SE93 for the transaction to be started, the user also requires the suitable defined authorization object (TSTA, table TSTCA).
If you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful, if you want to be able to protect a transaction with a separate authorization. If this is not the case, you should consider using other methods to protect the transaction (such as AUTHORITY-CHECK at program level).
• The system checks whether the transaction code is assigned an authorization object. If so, a check is made that the user has authorization for this authorization object.
The check is not performed in the following cases:
You have deactivated the check of the authorization objects for the transaction (with transaction SU24) using check indicators, that is, you have removed an authorization object entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.
This can be useful, as a large number of authorization objects are often checked when transactions are executed, since the transaction calls other work areas in the background. In order for these checks to be executed successfully, the user in question must have the appropriate authorizations. This results in some users having more authorization than they strictly need. It also leads to an increased maintenance workload. You can therefore deactivate authorization checks of this type in a targeted manner using transaction SU24.
You have globally deactivated authorization objects for all transactions with transaction SU24 or transaction SU25.
So that the entries that you have made with transactions SU24 and SU25 become effective, you must set the profile parameter AUTH/NO_CHECK_IN_SOME_CASES to “Yâ€