SAP Authorizations Evaluation of the authorization check SU53 - SAP Corner

Direkt zum Seiteninhalt
Evaluation of the authorization check SU53
Task & functionality of the SAP authorization concept
The programmer of a functionality determines where, how or whether authorizations should be checked at all. In the program, the appropriate syntax is used to determine whether the user has sufficient authorization for a particular activity by comparing the field values specified in the program for the authorization object with the values contained in the authorizations of the user master record.

Let's say that a user - we call her Claudia - should be able to edit the spool jobs of another user - in our example Dieter - in the transaction SP01. What do you need to do as an administrator? Each spool job has a Permission field; By default, this field is blank. If Claudia wants to see a Dieter spool job, the system will check if Claudia has a specific spool job permission with a value of DIETER. Claudia does not need additional permissions for its own spool jobs that are not protected with a special permission value.
System Security
The path with the associated permission group DEVL contains the local temporary files of the ABAP Frontend Editor of the ABAP development environment (transactions SE38, SE80, SE24, etc.). The two paths with the ADMN permission group show how logically related paths can be grouped into a S_PATH permission check. The two entries with the FILE permission group show how paths for Windows can be completed in systems with application servers of different operating systems. The core.sem and coreinfo entries are required to write run-time errors in the SNAP snapshot table. The dev_ and gw_ entries allow you to view files from the developer trace and Gateway Log in the ST11 transaction. If the suggestion in the first entry of the table is too restrictive, you can choose the alternative in the following table. This entry only forces a permission check on S_PATH and the ALL permission group; You should, however, only grant such permission very restrictively.

First, consider the transport of your proposed permissions from various development systems to a consolidation system. When you save permission proposal values in transport orders, you will notice that generic entries are used instead of detailed BOMs. These generic entries mark all applications, for example, with TR*..

The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".

If there are users in the daughter systems for which the value in the columns of the Contractual User Type and Value in ZBV Central differ, either the IDoc of the ZBV has not yet been processed, or the user type has been changed locally.

At you will also find a lot of useful information on the subject of SAP authorizations.

If you have developed your own permission checks to use them in your own programmes or to make extensions to the SAPS standard, it is essential that you maintain the Z authorization objects as suggestion values for the respective applications.
SAP Corner
Zurück zum Seiteninhalt