SAP Authorizations - A Common Perspective of Developers and Consultants
User Information System SUIM
If you select the SU24 Data Initialisation button, step 1 is the same and you overwrite your SU24 data with the SU22 data for the selected applications. The Auto Sync selection corresponds to step 2a. All new SU22 data will be transferred to the transaction SU24. Modified SU24 data is detected and must be matched manually. However, this information is provided to you in the Determined Synchronisation Status column. If you want to keep your SU24 data as it is for certain applications, select the button Set Status"Verified". To give you more transparency about the impact of your activities, there is a role usage proof via the Roles button. This allows you to check the roles in which the selected applications are used. With the Change Preview selection, you can see which suggestion values would be changed for your selection in the transaction SU24.
Depending on the configuration of root data and processes, different permission checks can be relevant, so that it makes sense to adjust the proposed values. If custom applications have been created in the form of Z-transactions, Web-Dynpro applications, or external services, you must maintain suggestion values for these applications to avoid having manual permissions in the PFCG roles. You must ensure that custom applications are not always visible in the SU24 transaction. This is the case for TADIR services and external services. To learn how to make these services available for suggestion maintenance, see Tip 38, "Use the SU22 and SU24 transactions correctly.".
Determine Permissions Error by Debugging
With the SAP NetWeaver 7.03 and 7.30 releases, Web Dynpro ABAP applications (as well as other Web Dynpro ABAP functions, see SAP Note 1413011) have been tested for permission to launch such applications. The authorization object that controls this startup permission is S_START. This authorization object is used in the same way as the S_TCODE authorization object.
The advantage of this feature is that administrators can parse failed permission checks regardless of end users. End users can save their unsuccessful checks to the database using the Save ( ) button. As an administrator, you can also back up failed permission checks from other users. The Saved Checks button also gives you access to this information afterwards. The automatic storage carried out when the old transaction SU53 was called is omitted because it overwrote the last recording. You can also load the results into an Excel file to allow a more comfortable evaluation.
With "Shortcut for SAP systems" you can automate the assignment of roles after a go-live.
It is essential to implement adequate authorization checks in every ABAP development.
Authorizations regulate the access of system users to system data and are therefore a fundamental prerequisite for the use of records and case management.