Show TOC

Background documentationAuthorization Checks

 

To ensure that a user has the relevant authorizations when he or she performs an action, users are subject to authorization checks.

The following actions are subject to authorization checks, which take place before the start of a program or table maintenance, and which cannot be avoided by SAP applications:

  • Starting transactions (authorization object S_TCODE)

  • Starting Web Dynpro applications (authorization object S_START)

  • Starting reports (authorization object S_PROGRAM)

    Caution Caution

    The authorization check only takes place if the program is assigned to an authorization group.

    End of the caution.

  • Calling RFC function modules (authorization object S_RFC)

  • Generic table access (S_TABU_DIS)

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 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 authorization 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 object 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.

Caution Caution

You must first adjust your roles and then activate the start authorization check. Otherwise, your users will no longer be able to run any Web Dynpro ABAP applications, since they will not have the relevant authorizations.

End of the caution.

For more information, see SAP Notes 1413011Information published on SAP site and 1413012Information published on SAP site.

1. Adjust the roles

For every Web Dynpro ABAP application and for certain application 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.

Note Note

Never manually insert start authorizations in roles, since this can mean that other required start authorizations are not added. These authorizations are only automatically added when you add the application to the menu of the role.

End of the note.

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.03 and 7.30.

    For more information, see SAP Note 1511363Information published on SAP site.

  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.

Note Note

Adjusting all roles takes some time. You have the following options to ensure that your users can continue working during the transition period:

  • Only activate the start authorization check once you have adjusted all roles.

  • If you want to activate the start authorization check before you have finished adjusting all roles (for example, for test purposes), you can create a copy of the role SAP_BC_WEBDYNPRO_ALL and assign it for the transition period to all users who are to be able to use Web Dynpro ABAP applications. This role contains full authorization for Web Dynpro ABAP applications and application configurations.

End of the note.
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 Reports

When starting a report with the ABAP statement SUBMIT REPORT, the system checks the authorization object S_PROGRAM, as long as the program has been assigned to a program authorization group in transaction SE38.

If this assignment is insufficient for your system environment, you can define your own group assignment with the report RSCSAUTH. You must check this assignment after installing support packages or upgrades, and reassign the reports if necessary.

Caution Caution

You cannot protect all programs with program authorization groups. Selected system programs, such as RSRZLLG0 and STARTMEN, and programs that are called during logon or with a SUBMIT in a customer exit, such as SUSR0001 and ZXUSRU01, cannot be protected with an authorization group.

End of the caution.

Note Note

When a report without an authorization group is called from the development environment (for example, SE38, SE80), the system also checks the authorization object S_DEVELOP with the activity 16.

End of the note.
Calling RFC Function Modules

When RFC function modules are called over RFC connections, for example, from an RFC client program or from another system, an authorization check is performed in the called system against the authorization object S_RFC.

In this check, the system checks the name of the function group to which the function module belongs. If this check fails, the system also checks the authorizations for the name of the function module.

Configure this check with the parameter auth/rfc_authority_check.

Generic Access to Tables

The system controls direct access to the contents of tables, for example with transactions SE16, SM30, or SE16N, with authorization checks on a table authorization group, object S_TABU_DIS. If no appropriate authorizations for the table authorization group exist, the system checks the name of the table or view, object S_TABU_NAM. While performing a change operation on client-independent tables, the system also checks the authorizations for the object S_TABU_CLI.

If you configured row-based authorization checks in customizing, the system also checks the authorization object S_TABU_LIN.

Assign tables or views to a table authorization group with transaction SE11 or SE54. You also define table authorization groups with transaction SE54.

If your custom development implements a direct access to a table, use the function module VIEW_AUTHORITY_CHECK to perform the authorization check.

For more information about generic access to tables, see SAP Note 1434284Information published on SAP site and the online documentation for the authorization objects named above.

More Information