During custom development, there are some essential points to keep in mind: security guidelines and best practices, segregation of duties (SoD) compliance, internal policy, and internal controls, among others. Understanding an SAP authorization concept can help you better develop and ensure correct governance and knowledge sharing in your SAP landscape. Because custom development allows for potential GRC pitfalls, ensuring a proper authorization concept in your SAP system is crucial to your GRC efforts.

This article explains some security best practices for managing and creating your custom development in a compliance landscape. I’ll provide a step-by-step guide to avoiding common errors during the release of your custom developments. Then I’ll show you a workflow-based methodology to clarify the phases, roles, and responsibilities during the release of a new custom development. Finally, I’ll discuss how to remediate a non-compliant situation that doesn’t reflect security best practices.

Let’s start by looking at a common authorization check workflow.

Workflow

Figure 1 shows an authorization check workflow divided into different phases. After the execution of a transaction code, the system checks if the transaction code is valid (defined into table TSTC). You can use transaction RSAUDITC_BCE (or administrative transaction SM01) to determine if the transaction is locked by the system administrator. If it is locked, a system message appears. If it is not locked, the transaction only starts if the user has the authorization in authorization object S_TCODE field TCD.

Figure 1

Authorization checks

After that, if an authorization object is directly assigned to a transaction code, it’s checked by the SAP system. Some SAP standard transactions already have an object assigned (which you can see with transaction SE93 or table TSTCA). If a user has this authorization object, the transaction code starts correctly. Otherwise, the process ends with a missing authorization error message. After these steps are completed, there are also all the authority checks in ABAP source code. AUTHORITY CHECK is an ABAP language statement that allows you to define the check at the program level on an authorization object. (Every program or report used by end users should be linked to a transaction code; see SAP Note 20534.) A user must have authorizations for all authorization objects inserted in the ABAP code for the transaction code to start. If one of the above checks fails, the transaction is not started, and the system displays a corresponding message.

The article focuses on all the points in Figure 1. When the business requires a new custom development (e.g., new transaction code), who are the actors involved? What are their responsibilities? I’ll provide the answers to these questions.

Baseline Security Guidelines

During the development of new capabilities in the ABAP landscape, there are some important guidelines and rules to apply by default. (See SAP Note 13202.) Critical Basis transactions cannot be released to end users (Table 1).

Table 1

Basis critical transaction codes

Transactions SA38 and SE38 allow end users to execute any program, while transactions SM3x and SE16x allow end users to edit or view any SAP table. To perform these activities (e.g., see a table, edit a table, or execute a program), it’s essential to have an authorization object to do it (e.g., S_PROGRAM for executing a program or S_TABU_DIS for displaying a table). For more about S_PROGRAM, see SAP Note 338177.

Query transactions SQ00 and SQ01 are connected to the authorization object S_QUERY if it is active, so these transaction codes are in edit mode. When the S_QUERY authorization object is not present in an SAP user ID authorization buffer and this user ID must execute a query with transaction SQ01, you must maintain an authorization group for queries with transaction SQ03 to grant access in display mode to the user ID. In these authorization groups, queries are assigned to user ID group members. Maintaining authorization groups for queries is often time consuming, so it is better to create a custom transaction code linked to a query with all the correct authorization objects.

If a business user must be able to view a table or a report, you need to create a custom transaction (i.e., a parameter transaction) to avoid using the standard transaction for data browsing tables or for executing the program (see also point 4 here). When releasing new capabilities, be careful to only release the program linked to the transaction code.

Create a Custom Transaction Code Linked to the New Custom Program

With transaction SE93, you can create a parameter transaction code. Insert a new transaction code and click the Create button (Figure 2).

Figure 2

Maintain transaction SE93

After you click the Create button, the system asks what type of object you would like to start with the new transaction (Figure 3). Select Transaction with parameters (parameter transaction).

Figure 3

Choose the start object

Parameter transactions allow you to pre-assign values to the fields on the initial screen. If you supply all the necessary entries for the initial screen in this way, you can suppress the screen when the transaction is executed by checking the Skip initial screen option (Figure 4). When transaction ZBC001 is defined and started, the system uses the standard critical transaction (e.g., SM30 or SA38) but skips the initial screen in Figure 4. At the bottom of the screen, insert the report to be started with transaction ZBC001 (e.g., in the Name of screen field: RS38M – PROGRAMM with RSPARAM in the Value field). In the case of transaction SM30, the appropriate values are those shown in Figure 5.

Figure 4

Create a parameter transaction based on transaction SA38

Figure 5

Create a parameter transaction based on transaction SM30

You can perform the same operation via transaction PFCG (Figure 6). During the definition of a simple role, you can create a linked custom transaction code (e.g., a report) in the Menu tab. Click the Report button and select one of the radio buttons (e.g., ABAP report). If you choose the ABAP report you need to insert the report name in the ABAP report section. You can also decide if the system automatically assigns the new transaction code name or if you want to define it. If you enter a report into a role, transaction PFCG automatically defines a transaction code. Otherwise, you can use your naming convention for your custom transaction code. To do this, uncheck the Generate automatically check box, insert the custom transaction name, and check the Adopt report description check box.

Figure 6

Link a report to a transaction code in transaction PFCG

Figure 7 shows the new custom transaction code inserted into the role menu. The role is ZBC001 and the description is Execute RSPARAM report. A new entry is also inserted into table TSTC with the newly created transaction code.

Figure 7

New transaction code created and inserted into the role menu

Behind these parameter transactions is a standard SAP table that shows the linked table or program. The table is named TSTCP (Figure 8). For a system administrator, it’s important to verify that the system is well patched and updated with last security-relevant notes. SAP EarlyWatch contains a check to determine whether or not the appropriate security-relevant notes have been implemented in the system with RSECNOTE tools (see SAP Note 888889).

Figure 8

Table TSTCP: parameters for transaction

Create a Custom Authorization Group and Assign a Table to It

With transaction code SE54, you can create a new custom user group (Figure 9). SAP view V_BRG_54 (in transaction code SE54) contains all the defined authorization groups. Table TDDAT (maintenance areas for tables) shows you how to link the table to the authorization group. (For more on this subject, see SAP Note 503149.) Figure 9 shows transaction code SE54 with the Authorization Groups radio button selected. Then click the Create/Change button to produce the screen in Figure 10.

Figure 9

Create a table authorization group

Figure 10

Insert authorization groups for table maintenance

Here you maintain authorization groups for tables. Click the New Entries button at the top of Figure 10 to create a new custom group for table maintenance (e.g., ZFIA — Financial Accounting).

For transaction SE54, select either Assign Authoriz. Group to link the authorization group you just created to a table or Authorization Groups to define a new authorization group (Figure 9). You can also assign an authorization group to a table by using transaction SE11 and following menu path Utilities > Assign Authorization Group (Figure 11).

Figure 11

Assign the authorization group to a table with transaction SE11

Create a New Authorization Object

With transaction SU21, you can create a new authorization object by clicking the new authorization object icon (next to letter B) in Figure 12. An authorization object should be inserted in an authorization class. You also need to regenerate SAP_ALL by clicking the Regenerate SAP_ALL button at the top of Figure 12. With table PRGN_CUST, you can customize the behavior of Regenerate SAP_ALL. For example, you can exclude your custom authorization object from the SAP_ALL profile by setting ADD_ALL_CUST_OBJECTS to NO, removing all authorization objects with a name that starts with a Z or Y from the SAP_ALL profile (Figure 13).

Figure 12

Transaction SU21

Figure 13

PRGN_CUST table

Before you define a new custom authorization object, you can search to find out if there is already a standard authorization object that fits your needs. Use the standard transaction code AUTH_DISPLAY_OBJECTS or use transaction PFCG and follow menu path Menu Environment > Authorization Objects > Display.

Link an Authorization Object at Transaction Code Level

You can insert an authorization object into ABAP code with the AUTHORITY-CHECK statement (which you can learn how to do here). The standard program RSXAUTHORITY-CHECK shows a graphical view of SAP authority check syntax. The AUTHORITY-CHECK statement and AUTHORITY_CHECK function module are different — see SAP Note 664897 for more information.  

Figure 14 shows an example of an authority check statement. In bold is the authority check statement on the V_KONH_VKO authorization object.

Figure 14

Authority check statement example

When a user ID tries to execute a transaction code linked to this program, the system checks in the user ID authorization buffer to make sure the V_KONH_VKO authorization object has the VKORG field, p_vkorg parameter value, and ACTVT field 03 (view) value. You can find all valid activities for each authorization object in table TACTZ. All authorization object fields with dummy values are not essential for an authority check.

How and Why to Link Authorization Objects at Transaction Code Level

When a new transaction code is defined and contains authorization objects, you should link all these authorization objects at the transaction code level. This action can help the authorization maintenance and reduce time during the user acceptance test. Use transaction SU24 to maintain these links (Figure 15). You need to know the names of the new custom transaction code and all authorization objects inserted at the ABAP code level. Then, in transaction SU24, you can add the S_PROGRAM authorization object by clicking the Object button in Figure 16. When you insert an authorization object, you can also insert the default values for the fields of the added authorization object (Figure 17).

Figure 15

Transaction SU24

Figure 16

Link an authorization object to a custom transaction

Figure 17

Inserted S_PROGRAM object with P_ACTION filled with the SUBMIT and VARIANT values

Proposal value YS (yes) indicates that when you create a new PFCG role in the Menu tab with these transactions, they are then automatically inserted in the Authorization tab. (For more, see SAP Note 113290.) A common problem is creating a transaction code with authorization object checks without maintaining transaction SU24. When the security manager creates a role with these transaction codes, the authorization objects are not automatically inserted in the Authorization tab. Consequently, when the users perform the user acceptance test, missing authorizations arise.

This example of missing authorizations is time consuming, so it’s a best practice to maintain transaction SU24 and not insert the missing authorization objects directly into the authorization role Menu tab manually. During the authorization maintenance phase and upgrade phase, the link between the transaction code and the authorization object is essential.

Keep in mind that when you add or remove a transaction code from the role’s Menu tab, all authorization objects linked to these transaction codes in the Authorization tab are added or removed consequently. If you insert an authorization object in the role Authorization tab manually, this object is not removed, though all transaction codes inserted in the role Menu tab are removed.

Behind transaction SU24 there are two tables: USOBT_C and USOBX_C. These tables are filled with corresponding tables USOBT and USOBX, which contain SAP standard authorization objects and values linked to the SAP standard transaction code SU25 when you install the SAP system.

A Workflow-Based Methodology for Managing New Developments

Figure 18 shows a workflow for managing the release of a new capability (e.g., a new custom transaction code).

Figure 18

Role and responsibilities workflow for new development

These are the steps outlined in Figure 18:

1. Business has a new request or needs to view or manage a new transaction
2. A business process owner (BPO) and other stakeholders (e.g., security administrators, key users, auditors, and developers) share the tasks. At this level, the BPO has already indicated the job role name of where to insert the new capability. A job role is a collective role assigned to an end user. All BPOs should have visibility to the following information: the job role master list, links between the job role and transaction code, and links between the job role and the user ID in the SAP system. The following are the steps performed by other stakeholders:
   • A developer analyzes the requirement and realizes the new capability
   • A security administrator shares and explains the SAP security concept that the company uses and knows which authorization objects and organizational levels are important
   • A key user can suggest your point of attention and point of view or enhancement
   • An auditor determines if the new capability clashes with an SoD process. The auditor then needs to understand if the new transaction can be inserted in an SoD matrix (e.g., a ruleset in the risk analysis and remediation [RAR] component of SAP BusinessObjects Access Control). A risk owner must be involved.

All phases of this process should be done in a meeting or, if the request is not complicated, with an email. It’s essential to write a document for tracing this request. This document template is divided into different sections (e.g., request, functional analysis, security analysis, and developer analysis). You can also insert this documentation in SAP Solution Manager.

3. After sharing knowledge and requisites, the developer starts the develop phase.
4. Who performs transaction SU24 maintenance: the security administrator or the developer that developed the new transaction code? There’s no one choice: It depends on your company’s situation. One solution is that the developer declares the authorization objects that are necessary in the document template and the security manager maintains transaction SU24.
5. After the developer phase, the security administrator transports new roles or updates roles into the QA system for testing purposes.
6. A key user performs an authorization test on two-way, negative, and positive capabilities. A positive shows that it does what it should, a negative shows that it does not do what it should not do, and a two-way shows both.
7. After the key user test, if there’s no rework, the security administrator transports the authorization role into the productive client.
8. The developer transports the new program into the production system.

9. The auditor reviews it.

How to Remediate in a Non-Compliant Situation

The methodology proposed is applicable in a new landscape or when a company changes its policy. Many companies have a previous situation that does not reflect the best practices proposed in this article.

It’s not easy to remediate such situations, and in some cases it can be expensive. Here are some tips and tricks for simplifying this challenge:

• Before working on the authorization object level, concentrate on the transaction code level first.
• Use a statistical approach to understand who uses critical transaction codes. Remove access to user IDs that do not use them and perform an interview with these users to see which programs and tables they really need to execute and use. SAP statistics can sometimes record which tables and programs are executed by a particular user ID, but make sure that you comply with national laws of privacy and worker protection in doing so.
• Use transaction ST01 to perform a system trace to understand which authorization objects and values are checked from a custom transaction code and populated in transaction SU24
• If you want to move from managing authorization group query transaction SQ03 to a custom query, use the RSAQ_IMPORT_USERGROUP_CATALOG function module or table AQGDBBN to understand which user IDs are assigned at which group.