The new transaction SU24N (Part 1)

The fact that the maintenance of authorization default values occupies a special position in the field of SAP security and role management has already been explained in detail in numerous blogs, such as “Xiting Best Practice Role Making – Optimal Role Making with PFCG & SU24” or “Advantages of Sustainable SU24 Optimization“. Nevertheless, their importance should be clarified again at this point, since the development of a sustainable and secure SAP authorization concept can only be guaranteed with the help of the authorization proposal values. Without them, sooner or later you will fail to achieve this goal. Such authorization proposals primarily assist in the adequate use of all objects in the single role menu (e.g., transactions, Web Dynpros, or gateway services) according to the stored authorization checks within the program code of the respective applications and are therefore essential for best-practice role maintenance and authorization management of your SAP system. In addition, the use of the authorization default values brings the following additional advantages, among others:

• Authorization assignment according to the “need-to-know” principle is technically guaranteed
• Enables the necessary and, at the same time, secure authorization maintenance and provisioning to the user master according to the existing ABAP code authorization checks (AUTHORITY-CHECK statement instructions)
• Granular and technically correct use of the profile generator during role construction
• Reduced maintenance effort due to automatic integration of authorization proposal values into the authorization profile in SAP Standard
• Maintaining a permanent up-to-datedness and ability to update the menu objects (applications) embedded in the roles when new transaction SU22 data is available (due to, for example, SAP release updates with new SAP default value definitions)
• Also simplifies the integration of customer-specific programs into the current authorization concept
• Creation of audit-based security checks and risk rules based on the authorization default values

Now, as of SAP_BASIS Release 7.54, the tried and tested tcode SU24, which has always been used to maintain those authorization default values (standard delivered and updates made to the customer table USOBT_C and USOBX_C tables), gets a new edition: transaction code SU24N. In the context of SAP S/4HANA with SAP Fiori, in addition to the standard transaction SU24, it is considered an extension for authorization proposal maintenance for access control.

Along with this, it offers essential new possibilities for authorization administrators. Therefore, in addition to general innovations, this blog post will primarily address the two most important changes during the introduction of transaction SU24N – the integration of change texts and proposal data variants. In a second blog, you will be introduced to the creation and use of transaction SU24N proposal data variants.

If you have problems with the new SU24N application, the following SAP Notes are helpful: https://launchpad.support.sap.com/#/notes/3036665 and https://launchpad.support.sap.com/#/notes/2798443

Please also note that SAP with SAP S/4HANA 2021 IS has adopted transaction SU24N and its new functionalities in the initial transaction SU24 and thus transaction SU24N no longer exists since this release.

General innovations

Compared to the known transaction SU24, authorization administration has an extended and detailed selection mask available with SAP transaction SU24N (Figure 1). Here you can now not only choose between a variety of new maintainable application types. New search scopes and display options are now also available to you. In addition, you can see all important system settings regarding authorization proposal value maintenance briefly.

In addition, you can now choose between the following default value statuses for the corresponding authorization objects within application maintenance (Table 1):

In addition, you can now switch between the display and maintenance options of the authorization data using the layout option “Proposal status: single-column/two-column”. Depending on the view, the name of the proposal statuses also changes. With a “single-column” view, the input option of controlling the test indicators separately is also omitted (Figure 2).

However, this is understandable due to the fixed connection between test indicators and default values. If, for example, you had set the check indicator of a certain auth object to “Do not check” in the past, the system automatically set the proposal status for the application to “No”. Therefore, a separate maintenance of the check indicators per se is not necessary since the corresponding authorization object is then not integrated into the authorization profile of the role if the check indicator is set to “no check”. There has therefore always been a causal relationship between the test mark and the proposal status, whereby the former is decisive as to whether a proposal status can be maintained for the corresponding application at all.

At this point, it should be mentioned that it is now also possible to automatically incorporate inactive authorization objects into the authorization profile of the role (“Set: Suggestion inactive”). This can be useful if you want to differentiate the scope of authorization in the role profile for certain applications according to the situation and per role.

In addition, you can now also use the view option “Compressed Object List” to filter directly on objects with the proposal statuses “Set: Proposal with field values”  or “Status: Set yes” or “Status: Yes, set without value” or display all of them, using “Complete Object List” (Figure 2).

Except for the subsequent far-reaching changes, there are still only minor technical and optical adjustments that are close to the previous transaction SU24. For example, you can now run an accurate and, above all, integrated transaction SU22 data synchronization, which in the past had to be carried out either manually or via transaction SU25. The integrative authorizations trace options (e.g., STUSOBTRACE, STAUTHTRACE or STUSERTRACE) can still be used with transaction SU24N.

Descriptions of transaction SU24 data

For the first time since transaction SU24 existed, it is possible to store descriptions and comments for authorization proposal values within this expert transaction – a milestone. This enables an essential improvement in the transparency of authorization proposal value changes in the system. This means that you can now make changes and at the same time include the decisions behind them or, if necessary, approvers directly in a change documents (Figure 3).

This not only simplifies change processes of authorization values, but also the assignment of changes if, for example, the processors or approvers have left the company and you then search in vain for the reasons for the respective maintenance status.

This can then be viewed currently, for example, through the print view within the transaction SU24 maintenance area of the respective application. For mass verification for several applications of these descriptions, you can also use transaction SE16(N) to read the table “SU2X_TEXT”.

Transaction SU24N proposal data variant

Another milestone, which is particularly decisive in the context of authorization maintenance, is the use of so-called proposal data variants for role construction. With the new transaction SU24N, you can now create and edit variants for authorization default values of a specific application. This allows you to map different access scenarios for the same SAP application. This means that you can create different variants for many scenarios according to the specifications and goals for an application (Figure 4). This is an absolute novelty in authorization proposal values and simplifies dedicated authorization assignments immensely, which did not exist in this form before.

In the previous way of controlling, for example, cockpit transactions (e.g., transaction BP or MIGO), you either had to leave all activity fields in transaction SU24 empty or create dedicated Z transactions for one and the same outgoing transaction. Subsequently, it was only possible to carry out the care individually in each end-user role depending on the situation to ensure a differentiation of the activity levels for certain groups of people. By creating a transaction SU24N proposal data variant for BP, for example, you can now create both a display and an attachment/change variant. These variants can then be introduced into the respective job function role using the new integration option in transaction PFCG. This allows you to save a lot of maintenance effort regarding the authorization proposal values within the roles. In addition, upgrade compatibility is guaranteed at any time without major maintenance activities, as was previously the case due to the open authorization fields.

By the way, the variants within the respective roles can be viewed via table AGR_APPL_VARS as a hash value. However, you then need, for example, the authorizations for transaction SE16 (S_TABU_DIS restricted by ACTVT and authorization groups or S_TABU_NAM restricted by ACTVT and table name). In addition, variant maintenance is only possible for applications. There is no variant of a variant. Further technical information on SU24N can be found in the official SAP Note 2809885. Furthermore, the SAP Note 2798443 is also helpful if you cannot make any changes in transaction SU24N and want to exchange information with the SAP Basis administrators here.

The creation of such a proposal data variant and the integration into a role via transaction PFCG will be discussed in detail in another blog. You must note that the mere creation of such a variant is not sufficient for use within the role. Only by integrating the corresponding proposal data variant takes effect and the respective characteristics are automatically loaded into the authorization profile by the profile editing function “Read old status and compare with the new data”.

Conclusion: Transaction SU24– Significant changes for authorization proposal value maintenance

Based on the blog, you can now initially see what profound and, above all, significant changes this new application (transaction SU24N) brings with it for the maintenance of authorization proposal value. You can now drill down individual and department-specific proposal data variants for each possible issue and make them available to end users. This is paired with a safer, more maintainable, and more sustainable role construction. In addition, the storage of description or change texts enables transparent traceability. Regarding best practice role construction, transaction SU24N is the most significant innovation, with the SAP_BASIS Release 7.54. These essential possibilities will provide tangible added value for all authorization administrators over the next few decades.

If you would like to learn more about our best practice approach to role building or if you need comprehensive advice during an SAP S/4HANA authorization migration or an authorization redesign, we are at your disposal. In addition, we offer you a variety of different services and products to support you in the maintenance of your authorization system. Just convince yourself in our weekly webinar on SAP authorizations.