Lesson 4 of 6
Diagnosing authorization failures
8 min
Listen to this lesson
"No authorization" is not a defect description. Security needs to know exactly which check failed, for which user, with which values, at which step. With that, a fix is usually quick and precise. Without it, the usual result is an over-broad fix that grants far more than needed. This lesson shows how testers capture that information.
SU53: the last failed check
Immediately after an authorization error in SAP GUI, the user enters /nSU53 in the command field. The authorization error analysis shows the most recent failed check: the authorization object, the field values the program asked for, and the authorizations the user actually has for that object. Depending on release and the analyst's own authorizations, it can also show the last failed check for another user, which helps when the tester is not available.
SU53 has limits. It shows only the last failed check, and not every failed check is the cause. Some programs check an authorization, accept a "no" and carry on with reduced function. If another check failed after the one that mattered, SU53 shows the wrong one. Fiori apps run their checks in backend sessions that are not the user's GUI session, so SU53 in a GUI window may not show what the app hit.
The authorization trace
For a complete picture, security or the test lead switches on the authorization trace with STAUTHTRACE for the test user, the tester repeats the step, and the trace is evaluated. It records every authorization check the user triggered, successful and failed, with object, field values and the program. It works for Fiori apps and background processing as well as GUI transactions. The general system trace (ST01) can also record authorization checks, but the dedicated authorization trace is easier to evaluate.
- Switch onSecurity or the test lead activates the authorization trace for the test user, for example T_WH_CHI_02.
- Repeat the stepThe tester reruns the failing step exactly as before.
- Switch offStop the trace so it holds only this attempt.
- EvaluateFilter for failed checks: object, field values and program.
- AttachAdd the extract, timestamp, system and client to the defect.
- Did the error happen in SAP GUI and can the tester run SU53 straight away?Yes → capture SU53 · No → ask for an authorization trace
- Does the SU53 object make sense for the step that failed?Yes → record it in the defect · No → trace the step to find the real failing check
- Was it a Fiori app or a background job?Yes → trace with STAUTHTRACE and check the gateway error log for service-level denials · No → SU53 is usually enough
- Is the denial expected by the role-to-process matrix?Yes → the negative test passed · No → log a role defect
Fiori-specific signs
In Fiori, an authorization problem can show as a missing tile (catalog not in the role), a message that the app could not be opened, or an error when data loads, often an HTTP 403 response behind the scenes. Service-level denials are recorded in the SAP Gateway error log (/IWFND/ERROR_LOG), which support teams can search by user and time. Object-level checks inside the backend appear in the authorization trace.
| Tool | What it shows | Best for | Blind spot |
|---|---|---|---|
| SU53 | The last failed authorization check | Quick capture right after a SAP GUI error | Misleading if a later, irrelevant check failed; may miss Fiori backend sessions |
| STAUTHTRACE | Every check for one user, passed and failed | Fiori apps, background jobs, unclear SU53 results | Needs someone to switch it on and repeat the step |
| Gateway error log | Service-level denials when an app calls its OData service | Fiori apps that open but fail to load data | Does not show object-level checks inside the backend |
Writing the role defect
| Field | Contoso example |
|---|---|
| Test user and role(s) | T_WH_CHI_02; goods movements and physical inventory roles |
| Expected access (from matrix) | Allowed: post goods receipt for PO in plant 1720 |
| Step and app or transaction | Step 3, post goods receipt in MIGO for PO 4500002210 |
| Failed check | Object for goods movements by plant; activity 01; plant 1720 |
| User's authorization for that object | Plant 1710 only |
| Evidence | SU53 capture or trace extract, timestamp, system and client |
A precise role defect. With this, security can fix the org value without widening anything else.
What would you do?
Contoso's AP clerk test user gets an error when loading the Manage Supplier Invoices app. The tester runs SU53 in a separate SAP GUI session and sees a failed check on an unrelated HR object. What is the best next step?
- SU53 shows the last failed check: fast, but not always the relevant one.
- STAUTHTRACE records every check for a user and works for Fiori and background processing.
- For Fiori, check the gateway error log for service-level denials as well as backend checks.
- A role defect names the user, roles, expected access, step, failed object and values, and evidence.
Check your understanding · not graded
Lesson check
1. What does SU53 show?
2. Why can SU53 mislead when diagnosing a Fiori app error?
3. Which transaction records every authorization check a user triggers over a period?
4. Where are Fiori service-level authorization errors logged?