The difference between S_PROGRAM and S_PROGNAM and the use of parameter transactions
Table of Contents
Introduction
Calling ABAP programs directly using generic transactions such as SA38 or SE38 harbors unwanted risks, since unrestricted access to other programs is often possible due to the authorization groups that have already been assigned. This can be avoided by granularly restricting authorization objects. In principle, the calling of programs in SAP is controlled via the authorization objects S_PROGRAM and S_PROGNAM, whereby the latter is only checked for generic report starts. Consequently, the check for S_PROGRAM always takes place as soon as the ABAP program is assigned to an authorization group. Targeted for generic transactions such as SA38 and SE38, SAP also offers the option of activating a further check for S_PROGNAM (program name). If the switchable authorization scenario BC_GENERIC_REPORT_START is activated via the transaction SACF, both the program group (S_PROGRAM) and the additional query for the specific program name (S_PROGNAM) are checked during generic report starts. Thus, when using generic report start transactions, the effective program execution can be restricted via the program name.
However, it is highly recommended to create so-called parameter transactions or report transactions instead. By using parameter transactions for individual programs, critical transactions such as the SA38 per se can be avoided and access to programs can be effectively restricted. In addition, parameter transactions can be classically authorized via the menu of roles, with which suitable authorization suggestion values from the SU24 can also be provided during the maintenance of the role profile. Since a transaction start no longer corresponds in principle to a generic report start, in contrast to the SA38 or SE38, only S_PROGRAM (program group) is checked even after the SACF scenario has been activated. It should be noted that in the START_REPORT transaction, only S_PORGRAM (program group) is always checked, since this transaction is often used as the basis for defining parameter transactions.
In this blog post, I will elaborate on the differences between S_PROGRAM and S_PROGNAM and show to what extent the XAMS can support in the analysis and maintenance of these authorization objects.
Structure of the authorization objects S_PROGRAM and S_PROGNAM
The authorization object S_PROGRAM first introduced by SAP is structured as follows:
The object is delivered with the fields P_GROUP (ABAB/4 program authorization group) and P_ACTION (ABAP/4 program user action), with the user actions giving the following choices for running ABAP programs:
| SUBMIT | Run ABAP programs |
| BTCSUBMIT | Schedule background processing programs |
| VARIANT | Create and maintain variants |
Similar fields exist for the newer authorization object S_PROGNAM:
This object is controlled by the fields P_ACTION and P_PROGNAM (program name with search help).
The basic difference between these two objects is thus in the fields P_GROUP and P_PROGNAM. In the former case, the restriction refers to program groups and in the latter case to individual program names. Behind the program groups there can be a large number of programs for which users would then receive correspondingly executable authorizations. Unlike P_GROUP, P_PROGNAM is granularly authorized to execute individual programs. Authorizing individual program names thus provides much more transparency and reduces the risk of accessing unwanted ABAP programs. For this reason, it is advisable to activate the additional check on S_PROGNAM for generic transactions (SA38, SE38).
Activation of the object S_PROGNAM
Since the authorization object S_PROGNAM was only introduced later by SAP (see SAP note 1946079, among others), it should first be checked via the transaction SACF (switchable authorization checks) whether this scenario of the authorization check is even present and activated. The scenario has the name BC_GENERIC_REPORT_START and must be enabled for active use of this authorization check:
However, extreme caution is required when activating this scenario. In order to avoid productive disruptions, the authorizations for the object S_PROGNAM should be included in the roles in advance. For this purpose, the transaction SACF also offers a corresponding logging mode in order to gradually extend the existing roles with the missing authorizations for S_PROGNAM. Because as soon as the scenario is active, in addition to the check for the program group via S_PROGRAM, there will also be a check for S_PROGNAM for the generic transactions. If the SACF scenario BC_GENERIC_REPORT_START_BATCH is also activated, this also applies to the planning and execution of background jobs, which is why activations in the SACF must always be carefully considered and planned well (see SAP note 2272827).
Use of parameter transactions
The combination of the generic transactions SA38 or SE38 together with the object S_PROGRAM can lead to critical risks in the area of the executable ABAP programs. This is because, for example, various programs can be executed using the generic transaction SA38 – provided the executing user has sufficient authorization for the object S_PROGRAM in one of his assigned role profiles. Unfortunately, this is often the case, so that S_PROGRAM and the P_GROUP field are marked with far-reaching authorization values. This scenario, in which users are given access to run various ABAP programs via transaction SA38, should be avoided as a matter of urgency. The recommended solution is to use so-called parameter transactions. In this way, it can be specifically guaranteed that the users of the SAP system can only run programs for which they should also be authorized via the role menu. In the best case, a parameter transaction is created for each program so that a granular restriction to individual programs is guaranteed. In the SAP standard, parameter transactions are created via the SE93. However, with the XAMS Role Replicator module, Xiting offers the possibility of creating parameter transactions in bulk as a substitute for, for example, the assignment of the SA38. This is an automation of the ABAP Workbench transaction SE93, in which the creation of parameter transactions is done via a single Excel upload. The format of this Excel file expects only the following values:
- Name of the transaction object
- Text of the transaction description
- Package name to which the transaction is to be assigned
- Parameters of the transaction that transfers the program name
An example of the structure of the required Excel file can look like this:
| Column A | Column B | Column C | Column D |
| Z_PARATCD1 | Parameter transaction 1 | Z_DEMO | RGRMTF00 |
| Z_PARATCD2 | Parameter transaction 2 | Z_DEMO | /SDF/AJM_SHOW_SM37_JOBLIST |
| Z_PARATCD3 | Parameter transaction 3 | Z_DEMO | Z_PROGRAMM_DEBITOR |
After the parameter transactions have been created, they can be included in a role menu. In order to be able to execute the parameter transaction, it is necessary to store the program group in the role profile via the SU24, provided that an authorization group has been assigned to the underlying program. The expression in the role profile would then look as follows for the parameter transaction Z_PARATCD1:
Maintenance of SU24 for S_PROG* parameter transactions
The use of parameter transactions is recommended to avoid allocation of generic transactions SA38 and SE38. In order to maintain efficient administration and transparency through the allocation of parameter transactions, proper maintenance of the SU24 default values for these transactions should be ensured. Proper maintenance means the concrete maintenance of program names or program groups of the authorization objects S_PROGNAM and S_PROGRAM using transaction SU24. In addition to the mass creation of parameter transactions, the XAMS Role Profiler module can therefore also be used to maintain mass SU24 default values of these transactions. This is the only way to ensure long-term manageable and transparent role maintenance. The Xiting Role Profiler module contains a report that specifically searches for parameter transactions that start executable programs. As soon as a program is assigned to an S_PROGRAM group, this transaction will appear in the report. In addition, the report checks whether the program group or the program name is properly stored in the SU24 default values of the affected parameter transaction.
The red traffic lights in the screenshot above show that the report has not found a stored SU24 default value for the example transaction Z_PARATCD1 and the object S_PROGNAM (field P_PROGNAM with value RGRMTF00) or S_PROGRAM (field P_GROUP with value GRWT). With this report, you can now update the SU24 default values of both objects for all listed transactions at the push of a button, provided that the program name or the program group of the program behind it is available. In our example, you would now add the program group “GRWT” for transaction Z_PARATCD1, so that the traffic light then changes to green, since the default value for object S_PROGRAM was updated accordingly in SU24:
Mass maintenance of the default values for S_PROGRAM or S_PROGNAM can also be implemented via the expert mode with this tool. With regard to the SACF scenario BC_GENERIC_REPORT_START_BATCH, it is important to maintain both objects.
Conclusion
The assignment of generic transactions such as SA38 or SE38 can lead to an increased risk, since in the worst case various or even all ABAP programs can be executed by users. For this reason, so-called parameter transactions should be created instead, which are only used to start individual programs. Since a large number of programs are often called via the SA38, the Role Replicator offers the option of mass creation of parameter transactions. The transactions created can then be included in a role menu and the users can be authorized accordingly via the role.
In addition, we recommend activating the authorization check for the object S_PROGNAM in order to protect yourself from calling various ABAP programs in generic transactions. In order to get an overview of the SU24 default values and also to maintain them en masse for parameter transactions, the Role Profiler report shown in this blog is ideal. This ensures proper analysis and maintenance of the program groups and program names behind parameter transactions. Before object S_PROGNAM can be used for generic transactions, however, it must first be ensured that the roles have been prepared accordingly and that the switchable authorization scenario BC_GENERIC_REPORT_START is activated via transaction SACF.
