Checking Authorizations

In ABAP programs, it is often necessary to check a users autorizations for special activities. For example, in ABAP programs, SQL Statements do not trigger authorization checks in the database system. Thus, Open SQL and Native SQL statements allow unrestricted access to all database tables. However, not all users have authorization to access all data that is accessible to the SQL statements in an ABAP program. When a program is released, it can be executed by any user with the relevant authorization. It is therefore the programmers responsibility to check that every user who can call the program is also authorized to access the data processed in it. Authorization Concept Authorization Checks

Checking User Authorizations (Authorization Concept)

Much of the data in an R/3 system has to be protected so that unauthorized users cannot access it. Therefore the appropriate authorization is required before a user can carry out certain actions in the system. When you log on to the R/3 system, the system checks in the user master record to see which transactions you are authorized to use. An authorization check is implemented for every sensitive transaction. If you wish to protect a transaction that you have programmed yourself, then you must implement an authorization check. This means you have to: allocate an authorization object in the definition of the transaction; program an AUTHORITY-CHECK. AUTHORITY-CHECK OBJECT <authorization object> ID <authority field 1> FIELD <field value 1>. ID <authority field 2> FIELD <field value 2>. ... ID <authority-field n> FIELD <field value n>. The OBJECT parameter specifies the authorization object. The ID parameter specifies an authorization field (in the authorization object). The FIELD parameter specifies a value for the authorization field. The authorization object and its fields have to be suitable for the transaction. In most cases you will be able to use the existing authorization objects to protect your data. But new developments may require that you define new authorization objects and fields. The following topics provide more information: Defining Authorization Checks

Defining Authorization Objects Defining Authorization Fields

Authorization Checks
For authorization checks, there are many ways of linking authorization objects with user actions in an R/3 system. The following discusses three possibilities in the context of ABAP programming. Authorization Check for Transactions You can directly link authorization objects with transaction codes. You can enter values for the fields of an authorization object in the transaction maintenance. Before the transaction is executed, the system compares these values with the values in the user master record and only starts the transaction if the appropriate authorization exists. Authorization Check for ABAP Programs For ABAP programs, the two objects S_DEVELOP (program development and program execution) and S_PROGRAM (program maintenance) exist. They contains a field P_GROUP that is connected with the program attribute authorization group. Thus, you can assign users program-specific authorizations for individual ABAP programs. Authorization Check in ABAP Programs A more sophisticated, user-programmed authorization check is possible using the AUTHORITY-CHECK statement. It allows you to check the entries in the user master record for specific authorization objects against any other values. Therefore, if a transaction or program is not sufficiently protected or not every user that is authorized to use the program can also execute all the actions, this statement must be used. AUTHORITY-CHECK OBJECT <object> ID <name1> FIELD <f1> ID <name2> FIELD <f2> ... ID <namen> FIELD <fn>. <object> is the name of an authorization object. With <name1>, <name2>, and so on, you must list all fields of the authorization object <object>. With <f1>, <f2>, and so on, you must specify the values that the system is to check against the entries in the relevant authorization of the user master record. The AUTHORITY-CHECK statement searches for the specified object in the user profile and checks the users authorizations for all values of <fi>. You can avoid checking a field <namei> by replacing FIELD <fi> with DUMMY. After the FIELD addition, you can only specify an elementary field, not a selection table. However, there are function modules available that execute the AUTHORITY-CHECK statement for all values of selection tables. The AUTHORITY-CHECK statement is supported by a statement pattern.

Only if the user has all authorizations, is the return value SY-SUBRC of the AUTHORITY-CHECK statement set to 0. The most important return values are:

0: The user has an authorization for all specified values. 4: The user does not have the authorization. 8: The number of specified fields is incorrect. 12: The specified authorization object does not exist.

A list of all possible return values is available in the ABAP keyword documentation. The content of SY-SUBRC has to be closely examined to ascertain the result of the authorization check and react accordingly.

REPORT demo_authorithy_check. PARAMETERS pa_carr LIKE sflight-carrid. DATA wa_flights LIKE demo_focc. AT SELECTION-SCREEN. AUTHORITY-CHECK OBJECT 'S_CARRID' ID 'CARRID' FIELD pa_carr ID 'ACTVT' FIELD '03'. IF sy-subrc = 4. MESSAGE e045(sabapdocu) WITH pa_carr. ELSEIF sy-subrc <> 0. MESSAGE e184(sabapdocu) WITH text-010. ENDIF. START-OF-SELECTION. SELECT FROM INTO WHERE carrid connid fldate seatsmax seatsocc sflight CORRESPONDING FIELDS OF wa_flights carrid = pa_carr.

WRITE: / wa_flights-carrid, wa_flights-connid, wa_flights-fldate, wa_flights-seatsmax, wa_flights-seatsocc. ENDSELECT.

In this example, the system checks with the authorization object S_CARRID whether or not the user has a display authorization (03) for the airline entered on a selection screen. If this is not the case, or a different error occurs, the Selection Screen Processing goes back to the display of the selection screen.