Authorization Checks 

When checking authorizations, there are many ways of associating authorization objects with user actions in an SAP system. The following discusses three options in the context of ABAP programming.

Authorization Check for Transactions

You can directly associate authorization objects with transaction codes. You can enter values for the fields of an authorization object when editing the transaction. 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 objects S_DEVELOP (program development and program execution) and S_PROGRAM (program editing) exist. They contain a field, P_GROUP, that is associated with the program attribute Authorization Group. 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 name₁ FIELD f₁
                        ID name₂ FIELD f₂
                        ...
                        ID name_n FIELD f_n.

object is the name of an authorization object. Using name₁, name₂ ... , you must list all fields of the authorization object object. Using  f₁, f₂ ... , you must specify the values that the system checks against the entries in the associated authorization of the user master record. The statement searches for the specified object in the user profile and checks the user’s authorizations for all values of f₁, f₂ ... You can avoid checking a field name₁, name₂ ... by replacing FIELDf₁  FIELD f₂ with DUMMY.

You can only specify an elementary field after the FIELDaddition, not a selection table. However, there are function modules available that execute the AUTHORITY-CHECKstatement 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 code sy-subrc of the AUTHORITY-CHECKstatement set to 0. The most important return codes are:

●      0: The user has an authorization for all specified values.

●      4: The user does not have the required authorization.

●      8: The number of specified fields is incorrect.

●      12: The specified authorization object does not exist.

A list of all possible return codes can be found in the ABAP keyword documentation. The content of sy-subrc must be examined closely to find the result of the authorization check and respond appropriately.

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  carrid connid fldate seatsmax seatsocc
    FROM  sflight
    INTO  CORRESPONDING FIELDS OF wa_flights
    WHERE 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 uses the authorization object S_CARRID to check 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.