Architecture of authorization concepts
Coordinate authorisation management in customer-owned programmes
The customising objects you have just created are now integrated into your own IMG structure. To do this, open the SIMGH transaction again, call your structure in Change mode, and paste it under the previously created folder by selecting Action > Insert a Level Lower. You should already create a documentation of the same name with the installation of the Customising objects. To do this, select the Create button on the Document tab and write a text to save it and then activate it.
In addition, you can also define customised permission checks in the SOS and also define combinations of authorization objects and their values. You can create up to 1,000 custom permissions checks in the Check ID namespace 9000 to 9999. You can also redefine whitelists for these permission checks, which apply to either individual or all of the customer's permission checks. The configuration is described in SAP Note 837490.
Authorizations in SAP BW, HANA and BW/4HANA
If an entry in transaction SE97 is correctly created, a permission check is performed in the same way as a transaction startup authorisation. This approach therefore requires an exact and complete configuration for each transaction that is invoked. The required effort and the space for errors are correspondingly large. The CALL TRANSACTION ABAP command does not cause a transaction startup permission check. Without a permission check, the ABAP programme could unintentionally allow users to access system resources. In many cases, such authorisation problems lead to a hidden compliance violation, because this means that the traceability of user actions in the SAP system is no longer guaranteed. A developer should not rely on the functionality of the SE97 transaction and therefore should include the possible permission checks in the code. Therefore, one of the following explicitly coded permission checks for the CALL TRANSACTION statement must be performed.
When configuring the Security Audit Log, you must consider the storage of the files. At least one separate file is created for each day. When the maximum size of all files for the tag is reached, additional events are stopped. So you should always adjust the maximum size of the file to your needs using the parameters rsau/max_diskspace/per_file and rsau/max_diskspace/per_day. The rsau/max_diskspace/local parameter is obsolete in this case, but remains active if the other two parameters are not maintained.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
You can do this by using the P_ABAP authorization object to override the usual permission checks.
Finally, you must include the new message definitions in your filters (transaction SM19).