Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

The authorization check

10 min

Listen to this lesson

0:00 / 4:21

Every time a user starts a transaction, opens an app or saves a document, the SAP system asks a question: is this user allowed to do this, here, to this data? The answer comes from a small set of building blocks that have barely changed in decades. Learn them once and every later topic, from role design to Fiori to audit, makes sense.

The building blocks

SAP's authorization concept is a hierarchy. At the bottom is the authorization field, the smallest unit a check runs against, such as ACTVT (activity) or BUKRS (company code). Fields are grouped into an authorization object, which holds between one and ten fields that are checked together. Objects are grouped by topic into object classes; finance objects, for example, start with F_. An authorization is one set of allowed values for an object's fields. Authorizations are collected in a profile, profiles are generated from roles, and roles are assigned to the user master record.

User master recordAna, accounts payable clerk at Contoso: the identity that logs on and carries roles
RoleMaintained in transaction PFCG: a menu of apps and transactions plus the authorizations they need
ProfileGenerated from the role; the technical container of authorizations
AuthorizationOne set of values for an object, for example display in company code 1710
Authorization objectUp to ten fields checked together, such as F_BKPF_BUK (accounting documents by company code)
Authorization fieldThe smallest unit: ACTVT, BUKRS, and so on
The SAP authorization hierarchy, from user to field.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-101

Activities

Most objects include the field ACTVT, which says what the user may do. The common values are 01 create, 02 change and 03 display; others include 05 lock, 06 delete and 08 display change documents. SAP stores all activities in table TACT and the activities valid for each object in TACTZ.

How the system checks

SAP's learning content describes two stages. When a transaction starts, a start check runs: the system checks object S_TCODE for the transaction code, then any extra object assigned to the transaction in its definition (visible in SE93). If either fails, the transaction does not start. Then, while the program runs, AUTHORITY-CHECK statements in the ABAP code check the objects that matter for the data. SAP's example: FB02 calls a program that checks F_BKPF_BUK with activity 02 and the document's company code. Fiori apps have their own start check on S_SERVICE for the OData services they use; lesson 5 covers it.

  1. LogonThe user buffer is built with all of the user's authorizations
  2. Start checkS_TCODE for the transaction, plus any object assigned in SE93
  3. Program checksAUTHORITY-CHECK on objects such as F_BKPF_BUK with ACTVT and BUKRS
  4. CompareRequested values are compared with the buffer
  5. ResultReturn code 0 allows; any other code denies, and SU53 records the failure
From logon to a yes-or-no answer.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-101

Every check is evaluated against the user buffer, built at logon and holding all of the user's authorizations. SAP's material lists the return codes: 0 authorized; 4 the object is in the buffer but not with these values; 12 no authorization for the object at all; 16 no profile in the user master. A user can see their own buffer in SU56.

One refused change in FB02: the start check passes, the program check finds the object but not the requested activity, and SU53 keeps the evidence.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-101

How values combine

Within one authorization, all fields must match: activity and company code together. Across several authorizations for the same object, any one that matches is enough. SAP's example: authorization A allows create, change and display in company codes 1000 and 2000; authorization B allows display in 1000, 2000 and 3000. The user can therefore change in 1000 and 2000 but only display in 3000. Mixing values from different authorizations never creates new combinations.

Values are matched within one authorization at a time, so A and B together allow change in 1000 and 2000 but only display in 3000.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-101

When access fails

Transaction SU53 shows the most recent failed checks for a user, including the object, the values requested and the user's current authorizations for that object. For a full picture of every check an app performs, administrators use the authorization trace (STAUTHTRACE) or the system trace (ST01). For Fiori apps, rely on the trace: the app's checks run in back-end sessions, so SU53 in a separate SAP GUI session often does not show them, and service-level denials appear in the SAP Gateway error log (/IWFND/ERROR_LOG). SAP's advice is not to turn trace results straight into new roles: check whether existing authorizations can be reused first.

What would you do?

During UAT, Maria cannot save a sales order change and sends Priya a screenshot of the error. Before anyone changes a role, what should happen?

Key points
  • Fields are grouped into objects (up to ten fields); authorizations hold values; profiles hold authorizations; roles generate profiles.
  • A start check on S_TCODE runs first; AUTHORITY-CHECK statements then check data-level objects.
  • Checks compare requested values with the user buffer; return code 0 means allowed.
  • SU53 shows the last failed checks; traces show every check an app performs.

Check your understanding · not graded

Lesson check

  1. 1. An authorization object groups:

  2. 2. Which ACTVT value means display?

  3. 3. Which object is checked first when a transaction starts?

  4. 4. A check returns code 4. What does it mean?