User and authorization management
FAQ
In addition to defining permissions for external RFC access through the S_RFC authorization object, it is possible to prevent external calls to function blocks. From SAP Net-Weaver AS ABAP 7.40 there is the additional SAP Unified Connectivity (UCON) layer. It controls external access to RFC function blocks independently of users or roles and can be configured to suit your needs. All function modules that are to be executable via RFC are entered into the UCON Communication Assembly. If a function block is not stored there, the call will be blocked. UCON has been designed to minimise impact on RFC call performance. The necessary function blocks are identified in the UCON Phase Tool (transaction UCONPHTL), which constantly monitors all external RFC calls and supports an introduction of the UCON Communication Assembly. This allows calls to new function blocks (such as custom developments, support package changes) to be analysed and, if necessary, released for external access. In addition, UCON offers the possibility to review the configuration in an evaluation phase. There are approximately 40,000 RFC-enabled function blocks in an ERP system; Usually no more than a few hundred of them are used. With the use of UCON you therefore increase the security of your system.
As part of identifying authorization problems, it should be documented what the risks are if the current situation is maintained. Often, those responsible in the company do not want to make a correction because it causes costs and work. If the current concept works and security gaps are abstract, many people in charge are reluctant to change anything. For these reasons, the first step should be to document what problems and dangers lurk if the current concept is not corrected: First, the risk of fraud, theft, and data privacy and security breaches increases. Documentation can help identify where dangers lie. There is a fundamental problem of financial damage to the company if action is not taken. Another danger is that users will experiment with their authorizations and cause damage that can be avoided by having a clean authorization structure. Also a problem is the increased administrative overhead of granting and managing permissions. The effort increases if the current role assignments are not transparent and optimally structured.
Map roles through organisational management
A separate programme - a separate permission. What sounds simple requires a few steps to be learned. Do you want to implement your own permission checks in your own development or extend standard applications with your own permission checks? When implementing customer-specific permissions, a lot needs to be considered. In this tip, we focus on the technical implementation of the authorisation check implementation.
No more users can be created, maintained or deleted without the assignment of a valid user group. If a user group is not assigned when a user is created, the user is automatically assigned the default user group. Before you set the USER_GRP_REQUIRED switch, a user group must have been assigned to each existing user and the administrators must have the permissions for the default user group. When creating a new user, the default user group will be used as pre-occupancy; this user group can be overridden by setting another user group in the S_USER_GRP_DEFAULT user parameter for each user administrator. The customising switch requires a valid user group, because it is used as the default user group. If a valid user group has not been entered in the customising switch, the user group is nevertheless a mandatory field. This will lead to errors in automated user creation.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
To do this, enter a user who will call the application you want to record, and then click Turn on Trace.
In transaction PFUD, which provides for the user comparison, the evaluation paths US_ACTGR and SAP_TAGT are used.