Authorization objects
Immediate authorization check - SU53
In the SU53 you get the entry of the user that is stored there, and this may be old. So it is better to let the user himself display the authorization error via the menu. Maybe you create a small docu for all your users how to display the error and where to send it, so a "Cooking Recipe: How To...". In the SU53 error excerpt, the first thing that is displayed is the authorization that the user is missing. So this object has to be analyzed. In the further part of the error message, the permissions assigned to the user are displayed. This information can be used to classify the user with his role set, where he belongs etc. Finally, in our case 1, we now have the missing authorization and must now clarify whether the user should receive this authorization or not. In addition the specialist department must be contacted, which has to decide whether the user receives the permission! It can happen that the problem reported by the user is not an authorization problem at all. Then the last authorization error is displayed in the SU53 area, which is not the cause of the error at all. Therefore, it is always good to have a screen image of the actual error message sent to you as well. It is not uncommon for developers to issue an authorization error of the type "No authorization for..." from their programs, but they have not checked this with a standard authorization check at all, so that the error is not an actual authorization error.
In order to be able to execute subsequent SAP standard reports, you need authorizations to access certain programs or reports and in the area of role maintenance. The transactions "SA38" and "SE38" for executing programs are of particular importance. They enable a far-reaching system analysis by means of certain programs for the end user. Additional rights associated with this, which can go beyond the basic rights of administrators, have to be controlled by explicit values in a dedicated manner.
Criticality
After defining the roles and generating the corresponding authorization profiles, the individual persons in the company are then assigned to the roles. In the process, the so-called user comparison takes place and the role-specific authorizations are stored in the user master record. The master record contains all information about an SAP user, including authorizations.
If you want your own developments to meet your security requirements, just like the standard, you must assign table permission groups to the custom tables. Custom tables, or SAP standard tables that you want to protect in particular, belong to separate, if applicable, customer-specific table permission groups. If extensive permissions are to be granted for system administration or certain applications, this is done with the S_TABU_DIS authorization object for the table permission group. Since many standard tables do not have a table permission group assigned to them and therefore automatically end up in the table permission group &NC&, you should restrict access to this table permission group. For example, certain tables such as T000 (clients) are in a large table permission group (SS: RS: SAP control); therefore, it is better to restrict access via a separate table permission group. You should also always assign custom tables to a table permission group, otherwise they will also be assigned the table permission group &NC&. Therefore, we will explain below how you can create table permission groups and map tables.
However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".
In case of a P_ABAP permission, the usual checks for authorization objects, such as P_ORGIN or P_ORGINCON, will no longer take place or will be simplified.
It is important that after the AUTHORITY-CHECK OBJECT command is called, the return code in SY-SUBRC is checked.