Introduction to the blog series
When creating a role in PFCG and adding objects to the menu, the authorizations maintenance will automatically merge authorization proposals from transaction SU24 into the role. How accurate and complete these proposals are, depends on maintaining accurate and complete SU24 proposals. Strong maintenance results in robust roles for the end user.
When entering a role in PFCG and navigating to the authorizations tab even when the menu has not changed (authorizations tab is green), there is also the option to enter the authorizations maintenance in “expert mode.” The SAP Note 113290 describes this function in detail. It isn’t called “expert mode” without reason: when faced with requirements to change authorizations with a role in mind, the expert methodology of doing this is to determine which transaction require change and maintain SU24 for that transaction accordingly. But the role will not know about this and other roles which can also benefit from the authorization proposal due to having the same transaction in the role will not either.
When and how to maintain SU24 is both a design question and even an art form to create elegant authorization concepts with complete where-used-lists and as little error-prone maintenance work required in the role itself via PFCG. Also how to design the SU24 in such a way that all roles profit from the proposed values. Ideally, doing everything via the menu or the organizational field levels decreases your workload in roles by about 90%. At the same time, increasing the role quality by at least the power of 90.
This blog series will share some tips and tricks with you for SU24 maintenance.
Which fields should always be maintained?
There are fields of objects which uniquely belong to applications – not only limited to transaction codes but also RFC enabled function modules, webdynpro applications, web servers and all other types of modern application types available in SU24 – for simplicity sake we use examples of transactions in the blog.
If the transaction is uniquely destined for a specific field value (e.g.,. transaction FB03 needs only field ACTVT value ’03’) or parameters are passed to it which are fixed values and needed in fields of authorization objects which will definitely be checked (e.g., Transaction XT30 needs only S_PROGRAM field P_GROUP value ‘TRZ’) then there is no reason not to add the field value to SU24. Also leaving a proposal field open in SU24 created “stupid work” as it has to redundantly maintain it in the roles.
Such field values are so to speak “clear as daylight” that they belong in an active SU24 proposal with field values if the transaction is also going to be used, as without them the transaction authorization makes no sense and without a fixed value you are likely to add more authorizations than needed in the role and thereby over-authorize the user for important object fields.
Example 1: ACTVT and other activities
The most important field you must be careful of is field ACTVT. It is used in thousands of applications with SU24 contexts and is very easy to maintain. But other fields also control “activity type” control via authorization objects but are not necessarily called ACTVT. Some other important examples are:
Tip: you can find more of them and monitor them via the XAMS Role Profiler Activity Watchdogs.
Example 2: P_GROUP and other parameters
There are also important fields of authorization objects in roles which do not control an activity type directly. By passing these fields as a fixed parameter from the calling applications to the target transaction, and the same field is authorization relevant – such as the program group on an executable program (Object S_PROGRAM). The parameter transaction, which needs nothing more nor nothing less, is the best example of such behavior.
Table TSTCP (parameter transactions definitions) contains more than 20 thousand transactions. The primary object needs these passing parameters as authorization values. Several other tables such as TSTCP and TDDAT and many others application types pass fixed parameters which are “clear as daylight” that they belong in SU24 if not there. The Role Profiler helps to identify the following important objects:
Tip: you can find more of them and monitor them via the XAMS Role Profiler SU24 optimizers.
Example 3: That which you once knew with certainty but did not take a note of
There are also important fields of authorization objects in roles which finding is difficult. Therefore, you can leverage code scanning programs, execute the program or transaction manually, or recover experience for previous projects. For these, you will have to test the transaction via a user equipped only with a role for this transaction and record all authority checks and field values. That is not scalable as typically you test a role (and that depends on the role…) or a user (and that depends on the auths of the user) so if over authorized it is very difficult to find out real values needed where the values are excessive.
For this we can offer three solutions with XAMS – consulting options are not available for this and only within XAMS.
XAMS Role Profiler SU24 Whitelist optimizer
All “clear as daylight” SU24 proposals which Xiting has found over the years to be missing are included in a list which can be analyzed and transferred to SU24. We use it ourselves since years in projects and update it regularly. You can reuse known missing proposals in SU24 automatically based on the transaction context.
XAMS ABAP Alchemist SU24 optimizer
For all unknown transactions (particularly Z* custom code) you can use the ABAP Alchemist to scan the code in development systems without needing a trace of the execution and find all authority-checks and propose them in a list. You can transfer the “clear as daylight” ones to SU24 with one mouse-click.
XAMS Xiting Times Simulation mode
For some check values, it is quite easy to build a role to at least 90% completion if you know what you are doing in the menu, and SU24 has a high quality. But some values might need an execution of the transaction to reach the check and reveal its values. Here the XAMS PTS (Productive Test Simulation) mode offers the capability to mirror new role authority-checks while users work normally with their old authorization roles in production to not only find out that an authorization field is missing, but also in which transaction context it is missing.
Previously in this series:
- SU24 Tips & Tricks - How to authorize menu navigation from application menus
- SU24 Tips & Tricks - How to authorize forward navigation from list reporting
- SU24 Tips & Tricks - How more authorization for an object is better than less
- SU24 Tips & Tricks - Fields which cannot be maintained
- SU24 Tips & Tricks - Fields which should not be maintained