SAP Authorization Check in ABAP: Understanding AUTHORITY-CHECK

Background Concept (Brief)

Authorization Objects (SU21): Group up to 10 authorization fields that together define a specific authorization (e.g., object F_BKPF_BUK for accounting documents per company code, with fields BUKRS (company code) and ACTVT (activity)).
Authorization Fields: The individual criteria within an object (e.g., ACTVT for activity like Display ‘03’, Change ‘02’, Create ‘01’).
Authorizations: Concrete values in the user master that define allowed values or patterns for the fields of an object (e.g., user Mueller may execute activity ‘03’ for company code ‘1000’ in object F_BKPF_BUK).
AUTHORITY-CHECK: Compares the field values requested in the code with the authorizations stored in the user master for the specified object.

Syntax

AUTHORITY-CHECK OBJECT '<authorization_object>'
                ID '<field_name1>' FIELD <value1>
                ID '<field_name2>' FIELD <value2>
                ...
                [ID '<field_nameX>' DUMMY]. " Optional

" Immediately after the check, sy-subrc MUST be evaluated:
IF sy-subrc = 0.
  " Check successful - user has the authorization(s).
  " Execute the protected code...
ELSE.
  " Check failed (sy-subrc <> 0) - user has NO authorization.
  " Output an error message, exit processing, etc.
ENDIF.

OBJECT '<authorization_object>': (Mandatory) The name of the authorization object (from SU21) as a character literal to check against (e.g., 'S_TCODE', 'F_BKPF_BUK', 'S_CARRID').
ID '<field_name>' FIELD <value>: (At least one ID addition, except when using DUMMY exclusively) Defines an authorization field of the object (e.g., 'TCD', 'BUKRS', 'ACTVT') and the value (a variable or literal) to check the user’s authorization against. You normally need to specify an ID/FIELD addition for all fields of the object that are relevant to your check.
ID '<field_name>' DUMMY: (Optional) Instead of a specific value, this only checks whether the user has any authorization for this field in the context of the object. This is sometimes used to check whether an object exists at all in the user profile, or to check for an activity without specifying it (although checking with a specific ACTVT value is more common). If only DUMMY fields are checked, you’re essentially only checking whether the user has the object in their profiles at all.

System Field `sy-subrc` (The Check Result)

You must always check the result of AUTHORITY-CHECK immediately afterwards in the system field sy-subrc:

sy-subrc = 0: Success! The user has the requested authorization.
sy-subrc = 4: No authorization. The user lacks the appropriate authorization for the checked combination.
sy-subrc = 12: No profile present. The user has no profile containing the checked authorization object.
sy-subrc = 8: Authorization incomplete (rare, occurs when authorization exists for fewer fields than specified in the check).
Other values (16, 24, 28, 32, 36): Indicate technical problems (user buffer faulty, field name in check incorrect, object not in system, etc.).

=> In practice, you usually check for sy-subrc = 0 for success and treat all other cases (sy-subrc <> 0 or sy-subrc >= 4) as “authorization missing”.

Where and When to Use?

Before allowing the user to perform a critical action (change data, delete, start special programs).
Before displaying sensitive data.
When access to data or functions should be restricted to specific organizational units (company code, plant, cost center, etc.).
In custom developments (Z-programs/classes) to ensure that users can only do what they are authorized for. Standard transactions and BAPIs often already contain built-in authorization checks (see SU24 for linking T-codes and objects).

Examples

1. Check Authorization for a Transaction

AUTHORITY-CHECK OBJECT 'S_TCODE'
                ID 'TCD' FIELD 'VA01'. " May the user start VA01?

IF sy-subrc <> 0.
  MESSAGE 'You have no authorization for transaction VA01.' TYPE 'E'.
  LEAVE PROGRAM.
ENDIF.

2. Authorization to Display Financial Data for a Company Code

DATA lv_company_code TYPE bukrs.
lv_company_code = '1000'. " Company code being checked

AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'            " Object for accounting document/company code
                ID 'BUKRS' FIELD lv_company_code " Check for this company code
                ID 'ACTVT' FIELD '03'.            " Check for activity 'Display'

IF sy-subrc <> 0.
  MESSAGE |No display authorization for company code { lv_company_code } present.| TYPE 'W'.
  RETURN. " Exit method/form
ENDIF.

" ... Code to display data for lv_company_code ...

3. Check with `DUMMY` (Whether Object Exists at All)

" Check whether user has any authorization for material master at all
AUTHORITY-CHECK OBJECT 'M_MATE_STA'
                ID 'ACTVT' DUMMY
                ID 'STATM' DUMMY.

IF sy-subrc = 12. " sy-subrc 12 = No profile found for the object
  WRITE: / 'User has no material master authorization at all.'.
ENDIF.

Important Notes / Best Practice

Always evaluate sy-subrc immediately after AUTHORITY-CHECK.
Implement clear error handling when sy-subrc <> 0 (e.g., output error message, abort processing).
Use constants (e.g., via CONSTANTS) for the names of authorization objects and fields to avoid typos and increase maintainability.
Coordinate with your company’s authorization management on which authorization objects and field values are relevant for your application and should be checked.
Check all relevant fields of an object that are necessary for the security of the action (often ACTVT is included).