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

Lesson 3 of 5

Authorization trace

9 min

Listen to this lesson

0:00 / 5:58

SU53 shows one moment. An authorization trace records every check a user triggers over a period, successful or not, with the values requested. Use it when the failure is buried in a long process, when a job or interface fails under a technical user, when Fiori apps call several services, or when fixing one gap keeps revealing another.

STAUTHTRACE and ST01

STAUTHTRACE, the System Trace for Authorization Checks, is an interface built for exactly this job. It uses the same mechanism as the general system trace ST01 but records and evaluates only authorization checks. You can restrict it to one user and run it on the current application server, all servers or selected servers; with more than one server, the evaluation adds a server column. ST01 can trace authorization checks too (choose the authorization check component and filter by user), along with many other components such as database access and RFC calls, but its evaluation must run on the same server as the traced activity.

  1. BeforeAgree the runWhich user, which steps, which data. Ana's invoice for 1710, from entry to posting.
  2. StartActivate the trace for the userSTAUTHTRACE, trace only for Ana's test user, on all servers.
  3. RunExecute the whole processAna runs every step in a separate session, including the save.
  4. StopDeactivate at onceTraces cost performance and grow fast; do not leave them running.
  5. EvaluateFilter and readRestrict to failed checks first, then review the successful ones for context.
A trace session from start to finish. The run should cover the whole process, not just the failing step.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203

Reading the result

Each entry shows the object, the field values requested and a return code. A return code of 0 means the check succeeded; any other value means it failed, and the precise meaning depends on the program. Read failures in time order and ask, for each one: did the program stop here, or did it handle the failure and carry on? A program that tries an object, fails and then tries a fallback will leave a failed entry that does not matter if the fallback succeeded.

Read trace entries in order: a failed S_TABU_DIS check followed by a successful S_TABU_NAM fallback is not a defect, but a failure where the program stops is.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203
SituationBetter toolWhy
One clear failure in an SAP GUI dialog stepSU53Quick, shows requested and held values side by side
Failure deep inside a long process or a saveSTAUTHTRACECaptures every check in sequence, including ones after the first failure
Background job or interface under a system or communication userSTAUTHTRACE for that userThe technical user cannot run SU53 interactively
Fiori app calling several servicesSTAUTHTRACE, plus the gateway error log for service errorsShows back-end checks for each service call
Collecting checks to improve SU24 default valuesTrace evaluation from SU24, or the long-term traceFeeds proposals rather than fixing one user

Choosing between SU53 and a trace.

Traces for better default values

Traces also improve role quality at the source. In SU24, the trace evaluation function reads a system trace (ST01 or STAUTHTRACE), locally or from another system through RFC, and lets you apply the recorded values as default proposals for the application, so every role that contains the app benefits. SAP also offers a long-term authorization trace for collecting checks per application across the system, switched on by profile parameter auth/authorization_trace and evaluated in STUSOBTRACE; check the documentation and notes for your release before enabling it in a shared test system.

Traces feed SU24, so the values learned once become proposals for every role that contains the app.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203
SU53 by the userA person, one failed dialog step: capture SU53 right away.
Trace the person's runA person, a long process with several gaps: STAUTHTRACE over the whole run.
Trace the technical userA job or interface with one failing call: trace that user while the job reruns.
Trace and review the designA technical user with many checks: trace, then reconsider what the user should hold.
Which tool fits: who runs the step, and how many checks are involved.
The Sign-Off Table · thesignofftable.com/academy/sap-sec-203

What would you do?

Contoso's nightly job that posts goods receipts from the warehouse interface fails in CMQ with an authorization message in the job log. The job runs under a system user. Kenji suggests giving the system user SAP_ALL in CMQ to get past it quickly. What should Sam and Nadia do instead?

Key points
  • Traces record every check over a period, successful and failed, with requested values.
  • STAUTHTRACE is the focused authorization trace; ST01 traces authorization and other components.
  • Return code 0 means success; read failures in order and ask whether the program stopped there.
  • Use traces for long processes, technical users, Fiori service calls and SU24 default-value maintenance.
  • Switch traces off as soon as the run ends.

Check your understanding · not graded

Lesson check

  1. 1. What does a return code of 0 mean in an authorization trace entry?

  2. 2. Why is STAUTHTRACE better than SU53 for a failing background job?

  3. 3. How does SU24 trace evaluation help role quality?

  4. 4. What is the main operational rule when running an authorization trace in a shared test system?