Authorization Checks

Checking at Program Level with AUTHORITY-CHECK

With the ABAP statement AUTHORITY-CHECK in the source code of the program, applications check whether the user has the relevant authorizations and whether these authorizations are appropriately defined, that is, whether the user administrator has assigned the values required by the programmer for the fields. In this way, you can also protect transactions that are indirectly called by other programs.

AUTHORITY-CHECK searches in the profiles specified in the user master record for authorizations for the authorization object specified in the AUTHORITY-CHECK statement. If one of the authorizations found matches one of the specified values, the check is successful.

Starting SAP Transactions

When a user starts a transaction, the system performs the following checks:

• It checks in table TSTC whether the transaction code is valid and whether the system administrator has locked the transaction.

• It checks whether the user has the authorization to start the transaction.

  The SAP system performs the authorization checks every time a transaction is called using the menu or the command field. Indirectly-called transactions are not included in this authorization check. There are additional authorization checks for more complex transactions that call other transactions.

  • The authorization object S_TCODE (transaction start) contains the field TCD (transaction code). The user must have an authorization that contains a value for the selected transaction code.

  • If you use transaction SE93 to enter an additional authorization for the transaction to be started using an authorization object, the user also requires this authorization object with the appropriate value ( TSTA, table TSTCA).

    When you create a transaction in transaction SE93, you can assign an additional authorization to this transaction. This is useful if you want to be able to protect a transaction with a single authorization. If this is not the case, you should consider using other methods to protect the transaction (for example, AUTHORITY-CHECK at program level).

• The system checks whether an authorization object is assigned to the transaction code. If this is the case, it checks whether the user has an authorization for this authorization object.

  This check is not performed in the following cases:

  • You have used transaction SU24 to deactivate the check of the authorization objects for the transaction using Check Indicators , that is, you have removed an authorization object that was entered using transaction SE93. You cannot deactivate the check for objects from the SAP NetWeaver and HR areas.

    This can be meaningful, since a large number of authorization objects are often checked when executing transactions, because other work areas are called in the background. For the check to be successful, corresponding authorizations must exist. This means that some users receive more authorizations than is absolutely necessary. It also means that more work is required to maintain the authorizations. You should therefore use transaction SU24 to deactivate authorization checks of this type in a targeted way.

  • You have used transaction SU24 or transaction SU25 to globally deactivate the authroization objects for all transactions .

  • For the entries made in transactions SU24 and SU25 to take effect, you need to set profile parameter AUTH/NO_CHECK_IN_SOME_CASES to the value Y (using transaction RZ10).

For the user to be able to start the transaction, all of the above checks must be successful. Otherwise, the transaction is not started, and the system displays a corresponding message.

Starting Web Dynpro ABAP Applications

This start authorization check is delivered in an inactive state. To use it, you need to activate it. Once you have activated it, you can use authorizations to control which Web Dynpro ABAP applications users can run.

For the start authorization check of Web Dynpro ABAP applications, the system uses the authorization object S_START in the same way as it uses the authorization object S_TCODE for transactions. The objects has the fields AUTHPGMID, AUTHOBJTYP, and AUTHOBJNAM, which correspond to the key fields PGMID, OBJECT, and OBJ_NAME of the object catalog (table TADIR). During the start authorization check, the Web Dynpro ABAP runtime therefore checks the key of the object catalog entry for the Web Dynpro ABAP application.

For more information, see SAP Notes 1413011 and 1413012 .

1. Adjust the roles

For every Web Dynpro ABAP application and for certain applicatino configurations, your users require a suitable authorization for the authorization object S_START to start the application. You therefore need to assign corresponding S_START authorizations to all Profile Generator roles for which the assigned users are permitted to run Web Dynpro ABAP applications.

To be able to assign Web Dynpro ABAP applications and application configurations, the administrator requires an authorization for the authorization object S_USER_STA with the field values AUTHPGMID = R3TR and AUTHOBJTYP = WDYA for Web Dynpro ABAP applications or AUTHPGMID = R3TR and AUTHOBJTYP = WDCA for Web Dynpro ABAP application configurations. The field AUTHOBJNAM must contain the names of the applications or application configurations that the administrator may assign, or the asterisk (*) for full authorization.

1. Use report RSAUTH_START_ROLES to determine roles for which the menus already contained Web Dynpro ABAP applications before SAP NetWeaver 7.0 EHP3 and 7.30.

   For more information, see SAP Note 1511363 .

2. Create a backup copy of all roles that you want to edit.

3. Add the Web Dynpro ABAP applications and application configurations to the role menu.

4. In the Profile Generator (transaction PFCG), select the role to be edited, and choose Change .

5. On the Menu tab page, in the Insert Node dropdown box, select the node type Web Dynpro Application .

6. On the Web Dynpro Application dialog box, select the Web Dynpro ABAP applications and application configurations.

   Enter the name of the application in the Web Dynpro Application field. You can use the description text automatically inserted by the system, or one of your own. If the application has different application configurations, you can select one of them in the Application Configuration field.

7. Save your entries.

8. On the Authorizations tab page, start authorization maintenance.

   The Profile Generator has automatically included the required S_START authorizations for all Web Dynpro ABAP applications and application configurations in the role authorizations.

9. Edit empty authorization fields.

2. Activate the start authorization check for Web Dynpro ABAP applications and application configurations

To edit the table, in addition to the usual authorizations required for transaction SM30, you need an authorization for the authorization object S_USER_ADM with the value PRGN_CUST in the field S_ADM_AREA.

1. Start table maintenance (transaction SM30), and, in the Table/View field, enter the table name USOBAUTHINACTIVE. Choose Maintain .

2. In the Inactive column, remove the indicator for the application types R3TR WDYA and R3TR WDCA.

3. Save your entries.

   You have activated the start authorization check system-wide in all clients.

Starting Report Classes

You can perform additional authorization checks by assigning reports to authorization classes (using report RSCSAUTH). For example, you can assign all PA* reports to an authorization class belonging to PA (such as PAxxx). If a user wants to run a PA report, he or she requires the corresponding authorization to execute reports in this class.

We do not deliver any predefined report classes. You need to determine yourself which reports you want to protect in this way. You can also use the maintenance functions for report trees to enter the authorization classes for reports. This method provides a hierarchical approach to assigning authorizations for reports. You can, for example, assign an authorization class to a report node, which means that all reports for this node automatically belong to that class. This means that you have a more transparent overview of which authorization classes are assigned to the different reports.

Take the following into account:

• After you have assigned reports to authorization classes, or changed the assignments, you may need to adjust objects in your authorization concept (such as roles, profiles, or user master records).

• There are particular system reports that you cannot assign to any authorization class. These include:

  • RSRZLLG0

  • STARTMEN (as of release 4.0)

  • Reports that, with a logon using a SUBMIT, are called in a customer exit (such as SUSR0001, ZXUSRU01).

• Authorization assignments for reports are overwritten during an upgrade. You therefore need to recreate your customer-specific report authorizations after an upgrade.

Calling RFC Function Modules

When RFC function modules are called from an RFC client program or from another system, an authorization check is performed in the called system against the authorization object S_RFC. This check is performed against the name of the function group to which the function module belongs. You can deactivate this check using the parameter auth/rfc_authority_check .

Checking Using the Assignment of Authorization Groups to Tables

You can also assign authorization groups to tables to prevent users being able to access tables using general access tools (such as transaction SE16), A user requires not only the authorization to call the tool, but must also have authorization to access the tables with the corresponding group assignments. We dliever tables with predefined assignments to authorization groups to allow this. The assignments are defined in table TDDAT; the checked authorization object is S_TABU_DIS.

To also protect tables that are not assigned to an authorization group, you can also use the authorization object S_TABU_NAM. It is integrated into the authorization check of the central function module VIEW_AUTHORITY_CHECK. In this case, the system first checks S_TABU_DIS. If this authorization check is not successful, the system also checks S_TABU_NAM.

For more information about S_TABU_NAM, see SAP Note 1481950 .