Security Automation for SAP Security Checks
Calling RFC function modules
Today we come to the error analysis with authorizations. The best thing that can happen is the error of the type: "I don't have authorization to do this and that!" (CASE1). Worse is the case that someone has too many permissions, i.e. the type: "User xy should not have this permission anymore" (CASE2). How to proceed? First of all we come to case 1 This case, that someone has no authorization for something, supports the system excellently! The code word is SU53! If a transaction encounters an authorization error, then this error is written to a memory area that can be displayed. For this there is once the transaction SU53 or the menu selection "System/Utilities/Anc authorization check". With this function, the system outputs information showing which authorization objects are missing for the user.
The critical permissions are defined in these steps: On the Entry screen, select the Critical Permissions button. You will now see two folder pairs in the dialogue tree: - Critical Permissions > Critical Permission - Critical Permission > Permissions Data. In Change Mode in the lower folder hierarchy, double-click the Critical Permission folder, and then select New Entries. In the right-hand pane of the screen, enter the appropriate data for the Eligibility, Text, Colour, and Transaction Code fields. Save your input. When saving, you are asked for a customising job. Please specify it accordingly. Select the entry you just created and double-click to open the Permissions Data folder to maintain the permissions data. Then create a variant. To do this, double-click the Variants to Critical Permissions folder and select New Entries. Enter the name and description of the variant and save your input. Now assign the identifier of the created critical permission to the variant. To do this, select the variant and then double-click in the Variants subfolder to get critical permissions > critical permissions in the input mask. Now click on New Items and select your variant from the list - in our example ZB01. Then save your input. Finally, you can run your report variant with critical permissions. To do this, go back to the RSUSR008_009_NEW entry screen and select the critical permissions option in the variant name pane. Now use the Value Help to select and run the variant you just created.
The SAP authorization concept
A new transaction has been added to evaluate the system trace only for permission checks, which you can call STAUTHTRACE using the transaction and insert via the respective support package named in SAP Note 1603756. This is a short-term trace that can only be used as a permission trace on the current application server and clients. In the basic functions, it is identical to the system trace in transaction ST01; Unlike the system trace, however, only permission checks can be recorded and evaluated here.
Here, the authorizations are either derived from the role menu (through the authorization default values (transaction SU24) or can also be edited manually in expert mode. The individual authorization objects are divided into object classes. For example, the object class AAAB (cross-application authorization objects) contains the authorization object S_TCODE (transaction code check at transaction start) with the authorization field value TCD (transaction code).
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
If, before mixing, permissions were already in the Maintenance status Standard (this applies to both Active and Inactive) or Inactive Standard, the underlying programme compares the values and the associated Maintenance Status of all eligibility fields and checks to what extent new suggestion values are present in the transaction SU24 and whether new permission fields must be added.
After all, if table logging is enabled, a log entry in the DBTABLOG table is generated for each change to the contents of a logged table.