Authorization, Basis and cross-layer traces — Root-cause case, remediation and assessment

Training simulation: All sample identifiers, logs, requests, transactions, values and cases are fictional. Tools and permissions vary by SAP release; perform any changes only in approved DEV/QA environments.

Authorization, Basis and cross-layer traces — Root-cause case, remediation and assessment

Incident: The same transaction works for one user but not another.

Landscape: SAP GUI/S/4HANA authorization infrastructure, PFCG, SU53, STAUTHTRACE and Basis diagnostics; cloud access varies.

Fictional incident dossier

TEST_USER clicks Approve InvoiceFiori tile opens, OData action returns 403CSRF check: passedSTAUTHTRACE: object M_RECH_WRK, ACTVT=02, BUKRS=DE10 denied (fictional values)Role TEST_AP_CLERK: ACTVT=03 only

Evidence observations

1. The role grants display activity but not approve/change activity, explaining the controlled denial.
2. The UI tile loads and CSRF passed, making a client-side routing error unlikely.
3. Authorization trace identifies the exact object/field values; it is stronger evidence than guesswork.

Three hypotheses

1. Role misses the documented approve activity for this company code.
2. CSRF token failure rejects POST even though PFCG grants business permission.
3. The backend service runs as a technical user with a different authorization assignment.

Supported: 1.

Evidence-backed root cause

The example TEST_AP_CLERK role intentionally has display-only activity; the attempted approval needs a narrower authorized change permission for the specified company-code context.

Safe remediation

The role owner validates job duty/SoD and adds the minimum approved authorization in a test role. Keep business DCL/service checks and promote through governed role transport.

Diagnostic runbook

1. Record affected end user, application and exact failed action; determine whether UI, OData, DCL or ABAP check rejects it.
2. Exclude CSRF/session and service-activation failure from the HTTP evidence before tracing business authorization.
3. Capture SU53 immediately after the controlled failure; if incomplete, run user/time-restricted STAUTHTRACE with Security approval.
4. Compare denied object and field values to actual PFCG role design and the business owner's required activity.
5. Request the smallest permitted role adjustment; never bypass AUTHORITY-CHECK or relax DCL globally.
6. Retest approved activity and an intentionally unapproved activity; record access-owner approval and audit evidence.

Confirm resolution

• Positive: Authorized approver can perform the exact action on the permitted company-code record.
• Negative: Display-only clerk still cannot approve even after the change.
• Cross-process: Restricted company code remains inaccessible and a cross-system technical user isn't overprivileged.

Assessment

Question: SU53 shows no decisive object but the action fails for one user. What is the appropriate next step?

A. Run an approved scoped STAUTHTRACE for the exact action and user.
B. Grant every authorization object.
C. Ignore backend authorization because the tile opens.

Correct: A. A trace helps establish which object/values were actually denied.

Safety: Do not recommend SAP_ALL, emergency IDs without governance, or broad customer access. Security trace data must remain confidential.

Synthetic case: The same transaction works for one user but not another.

The example TEST_AP_CLERK role intentionally has display-only activity; the attempted approval needs a narrower authorized change permission for the specified company-code context.

• A blank SU53 after a failure isn't evidence that authorization succeeded.
• A Fiori tile assignment and backend business permission are separate gates.
• Granting SAP_ALL can conceal a faulty requirement and violate Segregation of Duties.

The role owner validates job duty/SoD and adds the minimum approved authorization in a test role. Keep business DCL/service checks and promote through governed role transport.

• Positive: Authorized approver can perform the exact action on the permitted company-code record.
• Negative: Display-only clerk still cannot approve even after the change.
• Cross-process: Restricted company code remains inaccessible and a cross-system technical user isn't overprivileged.

Do not recommend SAP_ALL, emergency IDs without governance, or broad customer access. Security trace data must remain confidential.

Authorization and Basis debugging: SU53 limitations, authorization traces (STAUTHTRACE/ST01), role and profile comparison, system logs (SM21), work process analysis (SM50/SM66) and lock entries (SM12) — always with least privilege in mind.