This note explains the authorization checks when executing programs and development objects from the development environment point of view.
- In transaction SE38, you can execute reports without any additional authorization check; as of Basis Release 5.0, activity '03' (Display) of the authorization object S_DEVELOP is sufficient.
- When you use transaction SE37, for example, to test a function module, you require only activity '03' (Display) of the authorization object S_DEVELOP.
- A 'SUBMIT report' checks the authorization object S_PROGRAM only if an authorization group is entered in the attributes or properties of a program. If no authorization group is entered, the system does not carry out a check.
The authorizations for the development environment (authorization object S_DEVELOP) control only the access to the sources of the objects. The authorization object S_DEVELOP contains an activity '16' (Execute), but this activity is bound only to the execution of eCATT test configurations and is not used for the authorization check when executing programs.
In contrast, the authorization to execute a program is controlled by the authorization object S_PROGRAM.
Both authorization objects use the authorization group field together, which is also contained in the program attribute "Authorization Group". Therefore, you can use the authorization group to protect both the access to the program sources and the execution of the program. However, if no authorization group is entered for a program, the system does not carry out a check for the authorization object S_PROGRAM.
In addition, the authorization object S_DEVELOP knows the following authorization fields: package or development class, object type, and object name. Therefore, as of Basis Release 5.0, the activity 'Display' or '03' of the authorization object S_DEVELOP is also checked in the development environment. In some places (for example, in the test environment for function modules), this check is always performed. Therefore, there is an additional option of restricting the authorization for executing programs in the development environment (but only there).
According to the authorization concept, every critical report or function module checks the required authorizations individually or is protected by an authorization group.
To change this would not only cause extensive program changes in the development environment and in the runtime, but also a great amount of work to adjust the authorization profiles, for example, for existing customers. Therefore, a change via Support Package is impossible and not required from our point of view.
Since there are many places in the system where generic reports can be executed (for example, in transaction SA38 or SC38, and in many application transactions), it would also not be sufficient to make the authorization concept stricter in the development environment.
The program RSCSAUTH (available since Release 3.0C) is used to assign an authorization group to all executable programs or to individual programs or program groups. This ensures an effective protection.
You can do this without modification. You can transport the changes and copy them after a release upgrade.
For detailed information about this, see the documentation of the program or the installation guide.
If an executable program performs critical actions without having a sufficient authorization check, you can enter an error message on the component of the program.