How to analyze roles and authorizations in the SAP system
Consolidate user-level role mapping
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.
You can find the report RSUSR010 in the User Information System under the entry Transactions > Executable Transactions (all selections). You can run the report for users, roles, profiles, and permissions as described above. We will describe the evaluation for the users below (see figure next page above); for the other selection options, the operation of the report is analogous. The RSUSR010 report identifies all transactions that a user is allowed to start. In the list of executable transactions, you can then double-click on the transaction (for example, PFCG) to view the list of authorization objects and values for that transaction.
SAP S/4HANA® migration audit
You can use the function block level permission check by setting the FUNC value in the RFC_TYPE field in the S_RFC authorization object. If you still want to allow function groups, specify the value FUGR here. Depending on the RFC_TYPE field, type the name of the function block or group in the RFC_NAME field (name of the RFC object to be protected). This extension of the test is provided by the correction in SAP Note 931251.
So much information... how can you keep it so that you can find it again when you need it? Scribble Papers is a "note box" that makes this very easy.
The context-dependent authorizations combine the general and structural authorizations and avoid situations like in the example above. The context-dependent authorizations can be separated so finely that a separation of functions can be made possible without any gaps. Basically, with context-dependent authorizations, the authorization objects are supplemented by structural authorization profiles. This means that authorizations are no longer assigned generally, but only for the objects in the authorization profile. The use of context-dependent authorizations means that the familiar P_ORGIN authorization objects are replaced by P_ORGINCON and P_ORGXX by P_ORGXXCON. The new authorization objects then contain a parameter for the authorization profile.
Authorizations can also be assigned via "Shortcut for SAP systems".
In the example shown in the above figure, users of the BP-NRW Verifier Group would be left without comment when calling the vendor list for the period 01.01.2010 to 31.12.2014.
It is therefore useful to start the roles in the language which is also used most frequently, and also to cultivate the descriptive texts first in this language.