Sustainably protect your data treasures with the right authorization management
In the transaction, select SU10 by login data of users
When you mix roles, either after upgrading or during role menu changes, changes are made to the permission values. You can view these changes as a simulation in advance. As described in Tip 43, "Customising Permissions After Upgrading," administrators may see some upgrade work as a black box. You click on any buttons, and something happens with the permissions in their roles. For example, if you call step 2c (Roles to be reviewed) in the SU25 transaction, all roles will be marked with a red light, which requires mixing based on the changed data from the SU24 transaction. Once you call one of these roles and enter the Permissions Care, the permission values change immediately. Using the Alt, New, or Modified update status, you can see where something has changed, but you cannot see the changed or deleted values. A simple example of how to play this behaviour without an upgrade scenario is changing the role menu. Delete a transaction from a test role and remix that role. You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.
When the FIORI interface is called up, different roles (Fiori groups) are associated with factually related FIORI tiles. As an example, here is the group Master Data in which the FIORI tile "Manage Cost Center" can be found.
Add New Organisation Levels
When you start a report with the ABAP statement SUBMIT REPORT, the system checks the authorization object S_PROGRAM, provided that the program has been assigned to a program authorization group in transaction SE38. If this assignment is not sufficient for your system environment, you can define your own group assignment with the report RSCSAUTH. You must check this assignment after installing Support Packages or upgrades and reassign the reports if necessary.
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.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
So much information... how can you keep it so that you can find it again when you need it? That's what Scribble Papers is great for.
Consequently, important parameters such as the target machine, the client, the background user or also the password property can be checked in an overview.
This is the easiest and most effective defence to protect your business applications from misuse, because programming-level permission checks can ensure two things: Incomplete or incorrect validation of the executed transaction start permissions will result in compliance violations.