Define S_RFC permissions using usage data
Analyzing the quality of the authorization concept - Part 1
You will find all the user favourites of a system in the SMEN_BUFFC table; additionally there is the table SMEN_BUFFI, in which the links from the favourite lists are stored. You can simply export this table to Microsoft Excel and then evaluate it. At this point, however, we would like to point out that you may not evaluate the favourites without prior consultation with the users, because the stored favourites are user-related and therefore personal data. The SMEN_BUFFC table contains various fields that determine the structure of the placed favourites. For example, you can create folders in your favourites to sort them. This folder structure can also be found in the SMEN_BUFFC table. However, the entries themselves that you will find in the REPORT field are important for the re-creation of a permission concept. The REPORTTYPE field tells you whether the entry in question is, for example, a transaction or a Web-Dynpro application. In the TEXT field, if required, you will find the description of the favourite entry. In addition, you should also pay attention to the TARGET_SYS field, since favourites can also be entered for other systems, in this case an RFC target system is entered under TARGET_SYS.
When you create users in the SU01 transaction, do you want to automatically pre-occupy certain fields from a data source? Use a new BAdI for which we present an implementation example. If you create a user in the SU01 transaction in an SAP system, there is almost always data about that user in other systems. A classic example is user data in the Active Directory or the personnel master data in SAP ERP HCM, which are already maintained as part of the employee recruitment process. If user data is present in multiple systems, then the first choice is to automatically create a user through an identity management system, which is resolved by an HR trigger in SAP Identity Management (ID Management). ID Management detects changes, such as personnel master data, SAP ERP HCM, or business partners in SAP CRM, and either applies the appropriate users in your systems or makes changes and deactivations. But what if you don't have an identity management system in place? Do you need to type all of this data? No - you can pre-document them automatically. You can use a Business Add-in (BAdI), which allows you to pre-define certain fields when you create a user in the SU01 transaction.
Using eCATT to maintain roles
Depending on the transaction invoked, the application can be more granular checked by this additional permission check. Therefore, transactions that are called with additional parameters might require more than one authorization object and must be protected programmatically. The following listing shows an example of a permission check that ensures that the logged-in user has the permission to start the SU24 transaction.
Structural authorizations work with SAP HCM Organizational Management and define who can be seen, but not what can be seen. This is done based on evaluation paths in the org tree. Structural authorizations should therefore only be used together with general authorizations. Just like the general authorizations in SAP ECC HR, they enable regulated access to data in time-dependent structures. An authorization profile is used to determine the authorization. In addition, it is defined how the search is carried out on the org tree.
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.
The SAP authorization concept must generally be created in two versions: for the ABAP stack and for the Java stack.
If you want to know more about SAP authorizations, visit the website www.sap-corner.de.
We present the report, which only requires the permissions a auditor usually has to view the system modifiability.