SU24 Tips & Tricks – How to authorize menu navigation from application menus
The first three blogs dealt with fields which you should and respectively should not, or even cannot maintain as SU24 proposals for roles. The 4th blog dealt with creating instances of authorization objects within single roles instead of single role instances in composite roles. This simplifies your concept and you gain better control over the maintenance of roles. The 5th blog introduces the idea of robust roles with further navigation from lists.
The 5th blog, about list navigation, introduces the concept of implementing “friends” in SU24 for fixed value navigation. Also, it shows how to maintain SU24 to suite your control requirements for how deep and far a user can navigate based on the list report they have as an entry point and authorized selection. It also introduces the ABAP statement CALL TRANSACTION.
Table of Contents
How to authorize menu navigation from application menu
This blog relates to the concept of “friends,” but a different flavor of it. It is about finding hierarchies of friends to make your concept clearer and more maintainable. Especially when they are not easily recognizable as friends of each other. There where the user cannot directly tell what application they use but only how they get there. Additionally, some unchecked navigation is not wanted. You can easily control it using this approach. Then you only need to investigate it once in SU24 and apply the control to all roles automatically.
You will have reached 99.9% field value completion of your roles and have where-used-lists references to all objects in the menu. That allows you to exactly see why an object is in the roles and what will happen to the user at object level if it is not in the role. You are already in control of your authorization concept from a maintenance perspective of the roles. You now want to reach 120% completion to make the roles robust beyond what the users or ST03N data can tell you, but still, control what they could access. This also decreases the future maintenance overhead of the roles already at the time of building them. Because you mostly know these “friends” well, you can prepare SU24 with what suits them should they ever try to use menu navigation.
The difference between list navigation and menu navigation
As mentioned, there is a difference between list navigation (5th blog) and menu navigation (this blog). Lists have data in them and pass parameter values, so the target transaction relates to the source transaction reporting and its original documents.
Menu navigation can in theory and practice go anywhere as no parameter values are mandatory to pass in the navigation. So the certainty that the navigation belongs to the source transaction is not guaranteed. There are as many examples where it is sensible as what there are examples where it is not – so you want to control it.
From a user perspective, they are not clicking on a line item to do something with it. They are clicking on a higher level menu option or taskbar button. What it does is freely definable by the code behind the button and does not have to relate to any line item or previous authorization restrictions you have in place.
Reason 1 to do it: Display client settings from the TMS
The transaction STMS is an application with a strong organizational element to it. It depends on who transports which types of requests, who monitors transports, who reports on or audits changed objects and finally also the basis administrators who configure the transport system beyond system/client boundaries. Accordingly, it is potentially critical but also very popularly for various groups of users.
From transaction STMS you can navigate to various screen programs (system overview, transport routes, import queues, job monitors, etc.) which have various individual menus for further navigation.
Let’s take a look at STMS -> Overview menu -> Transport Routes -> Environment Menu -> Client Settings (SCC4) or System Change Options (SE06). Obviously, the STMS has to respect those settings in its application and read the settings. It offers a convenient navigation to the applications via CALL TRANSACTION so that administrators can go directly from STMS to SCC4 and make changes if needed. Also, he can go directly back again. However, display type users of STMS (e.g. auditors, key users, developers who should only have display access in production, etc.) will also want to use these navigation conveniences, but without needing to ask for the transaction in the menu of their roles.
So what you want to do is to add application authorizations to the SU24 proposals of STMS. This covers these likely navigation paths in display activity modes. That allows the user to use the navigation convenient. But it is clear for them that they are not meant to change anything. Also, and most importantly, they will not bother you for the access.
Here you can see that SCC4 and display access to table T000 is added to SU24 of STMS. That means that the navigation is permitted without the users asking for more access to SCC4.
Tip: for such multi-purpose transactions, such as STMS, it also makes sense to generally set the access to display for all objects as in the image above. If the user needs to create transports, or import them, or change the configuration, then they require stronger authorization than STMS in the menu of a role to be able to do that. Various other more precise transactions are available within the STMS (e.g. STMS_IMPORT, STMS_EXPORT, etc.). Also, you can propose stronger access in SU24 for specific transactions, which are only known and given to administrators.
Reason 2 not to allow it: System change option and installation tasks
Menu navigation is mostly implemented as a CASE statement in ABAP which reacts to the user command. The user initiates the command by what they click on in the menus or taskbars. These often implement CALL TRANSACTION as the navigation statement so that the user has the option of going back to the calling application. That is convenient, and as we know from list navigation, it is sometimes even wanted that the user should not be able to access the called transaction directly. So, all is well, by default, normally…
With menu navigation, there is, however, no direct link between the calling application and the called application as it does not have to pass parameter values. So the call could be made against any transaction even if unrelated and therefore likely to be unwanted.
An Example
For instance, STMS also offers navigation to SE06 – the system change options. While the STMS must read those settings, SE06 also offers functionality unrelated to STMS and is way too powerful for even a display user of STMS. You can, for example, reinstall the system or perform a database copy or a database migration.
Due to the CALL TRANSACTION, you will not be able to control the start of the called application (SE06). Therefore, you must rely only on the application authorizations that a user cannot make changes. Sometimes that is enough, but sometimes it is not. Do not add it to the SU24 proposals of STMS or change it to display, if technically possible.
To block the application navigation, SAP offers transaction SE97. It is similar to SU24, but it is calling application specific. However, in this special case, the check does not have to be in the ABAP coding. Though, it ideally should be via a call to function module AUTHORITY_CHECK_TCODE. So that you are able to add an error message to the navigation.
So you can make the check stricter again without having to change the ABAP code. That allows you to prevent the navigation at the start of the application. However, unless the user, in fact, has the authorization to start the transaction.
Tip: via SE97 you can also gain an overview of the called transactions which the calling transaction has an ability to navigate to. These are generally maintained but not always a complete list and not always maintained with “check indicators” which suits your concept for authorization control.
Conclusion
Using the tips from these first six blogs you will typically still be at 99,9% field completion of your roles. In addition, you will reduce maintenance on your roles in the long run. On top, you have a better understanding of how to make the initial investment in maintaining SU24 correctly for intended navigation. Also, you can control potential navigation correctly by either allowing it from the start or blocking it if not controlled.
As the level of maturity of SU24 proposals increases, you increasingly have the confidence in administrating the roles only via their menus and the organizational field values maintenance.
In this way, you define a concept for the roles and maintain metadata for them. The actual generation and the field maintenance of hundreds of objects in hundreds of roles via PFCG are now automated via the menu for robust single roles. Ideally, you have less than 100 master single roles and control the thousands of authorization instances in them via SU24.
Previously in this series:
