Unclear responsibilities, especially between business and IT
Advantages of authorization tools
There are several ways to view the implementation of permission checks: Either you jump directly from the system trace for permissions to the appropriate locations in the programme code, or you go over the definition of the authorization objects. To view the permission checks from the permissions system trace, start the trace from the STAUTHTRACE transaction and run the applications you want to view. Now open the evaluation of the Trace. In the Programme Name column, you can see the programme that includes the Permissions Check. Double-click to go directly to the code site where the permission check is implemented.
Further changes can be found when using the proof of use. When you click on the button (proof of use), you will receive a new selection. You can check which permissions, SU24 suggestion values, or SU22 suggestion values the authorization object uses. The ABAP-Workbench selection, as in previous releases, provides you with the proof of use for implementing the authorization object in programmes, classes, and so on. You can use the SAP NEW Data button to mark whether this authorization object is relevant to an SAP New role of a particular release.
Take advantage of roll transport feature improvements
In addition to your custom authorization objects, you must also express the other relevant CO-PA authorization objects in your users' permissions. As a rule, you must limit access to the result reports of the K_KEB_REP object to the result area and the report name, and limit the functions of the information system in the K_KEB_TC object, such as executing or updating reports. You also need permissions to maintain the authorization objects in customising the result and market segment calculations. To do this, assign permissions to the K_KEPL_BER object. In the CERKRS field, define the result area for which authorization objects are created, and in the ACTVT field, define the activity, where the action 02 is Create and Modify.
For these scenarios, there are several ways to determine which systems and clients to display to the user in the self-service selection. We therefore describe a possibility that you can use in all scenarios. To do this, use the BAPI BAPI_USER_GET_DETAIL, which you must call for the SAP User ID on all relevant systems. Check the entry for the RETURN table parameter first. If the entry is empty, the user is present in the SAPS system. Any error messages during the call are displayed in this parameter (e.g. if the user is not present). If the PROFILES or ACTIVITYGROUPS table parameters have entries, permissions in this system are assigned to the user. In addition, you can use the REF_USER export parameter to identify a reference user that is associated with it. However, you must also check that it has permissions. You can also determine if a lock exists when you call the BAPI BAPI_USER_GET_DETAIL. To do this, use the ISLOCKED export parameter, which returns a four-character combination of the L (locked) and U (not locked) characters.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
We'll show you how it's easier.
The EWA does not only contain security-related tests and is therefore divided into different sections (e.g. hardware, performance).