AUTHORITY-CHECK and SAP Authorization Objects

Authorization objects define fields such as activity (ACTVT), company code, plant or application-specific dimensions. PFCG roles generate authorizations containing allowed value combinations. AUTHORITY-CHECK asks the authorization kernel whether the current user's buffer contains a matching authorization instance. S_TCODE controls transaction start but does not automatically authorize every business action inside the transaction. Frameworks can perform their own checks, and CDS DCL provides row-level authorization for CDS consumption. A custom program may require both transaction/service access and application object checks.

Use AUTHORITY-CHECK before protected read/change actions in custom classic ABAP where no higher framework already guarantees the business authorization. Use the standard authorization object for the application if one exists; creating a Z object is justified when the custom business concept has no suitable standard control. Check exact business values, not '*' as a shortcut. In RAP/ABAP Cloud, use the framework-supported authorization mechanisms and instance/global authorization hooks as appropriate rather than scattering classic checks arbitrarily.

PFCG roles supply values; SU24 can propose defaults for transactions; SU53/STAUTHTRACE diagnoses failures. User buffers hold generated profile authorizations. Transaction/Fiori catalog access is only one layer. CDS DCL can restrict data returned by CDS; it complements action checks rather than replacing every operation authorization. RFC/OData executes checks under the backend identity, which may be technical or propagated.

A Z report displays purchase orders and allows a custom 'release' action. S_TCODE only controls whether the user can start the report. The release code performs AUTHORITY-CHECK for the appropriate purchasing authorization object with ACTVT and organization values before changing the document. A user can therefore view but not release outside their purchasing organization. Security traces prove the exact object/field values when access is denied.

Authorization objects/AUTHORITY-CHECK remain core in S/4HANA private/on-premise, while RAP, CDS DCL and Fiori role content add newer layers. Clean-core custom development should use released/framework authorization contracts, but the principle of server-side business authorization remains unchanged.

Security/application architects define objects and values; ABAP developers place checks correctly; PFCG role teams grant least privilege; business owners approve organizational scope; audit tests effective access.

PFCG roles provide values; SU24/SU53/STAUTHTRACE support design/diagnosis; CDS DCL covers row-level data authorization; BTP identity topics determine which backend user is checked.

Production verification: Capture the actual backend user, client and system, failing action, authorization object and field values, assigned roles and validity, trace timestamp, and whether execution was dialog, RFC, background, or propagated from Fiori or BTP. Reproduce under the real identity and correct the least-privilege role rather than testing with SAP_ALL.

Operational readiness: For production readiness of AUTHORITY-CHECK and SAP Authorization Objects, test with a representative least-privilege business user and with the actual technical or propagated identity used by integrations. Record both allowed and denied scenarios so the role design proves separation of duties rather than merely eliminating errors. Any change that broadens access should identify the business owner and authorization-field scope, and the post-change test should use trace evidence rather than relying only on successful screen navigation.

Review checkpoint: Review checkpoint for AUTHORITY-CHECK and SAP Authorization Objects: validate the design with at least two users whose organizational scope differs, then capture trace evidence for an allowed and denied operation. Confirm role validity dates, generated profile or user comparison state where applicable, and the actual backend identity used by Fiori, RFC or BTP calls. The production runbook should say which team approves broader access, which authorization fields are business-sensitive, and how emergency access is separated from permanent role design. This turns a one-off authorization fix into a repeatable least-privilege control.