RAP Authorization: DCL, Global Authorization and Instance Authorization
RAP authorization has multiple layers: CDS DCL restricts which entity rows a user can read, while behavior authorization controls whether create, update, delete and actions are allowed. Global authorization answers permissions independent of one instance; instance authorization evaluates permissions for specific business-object instances. A user can therefore be allowed to read a row yet be forbidden to update or execute an action on it.
Practitioner guide to RAP Authorization: DCL, Global Authorization and Instance Authorization, with architecture, use cases, worked example, decision criteria, pitfalls, S/4HANA context, ownership and production verification guidance.
Reviewed by an ERPClimb SAP consultant on 20 Sept 2026· 705 words
What it is
A RAP business object defines authorization control in its behavior definition. The behavior implementation provides authorization results through framework methods for global and/or instance checks depending on the model. Global authorization is suited to operations whose permission is not tied to one row, such as create or broad action capability. Instance authorization receives business keys and can decide based on owner, company code, status or other instance attributes. CDS access control (DCL) runs on read access and filters rows according to authorization roles/conditions. UI feature control can hide/disable actions but is not a security substitute for backend authorization.
When to use it
Use DCL when row visibility must be restricted consistently for CDS consumers. Use RAP global/instance authorization for modification/action permissions in the business object. Keep authorization checks server-side and return failed/reporting messages through RAP conventions. Do not rely on Fiori button visibility. If authorization logic needs organizational data, read it efficiently in bulk for all requested keys rather than issuing SELECT per instance.
How it fits the stack
Fiori/OData authenticates a user and calls the RAP service; DCL can filter reads before data reaches the UI; RAP authorization methods are invoked by the behavior runtime for requested operations. PFCG/backend authorization objects remain the underlying entitlement source where custom logic uses AUTHORITY-CHECK. Service/ICF/catalog authorization is an outer layer. Draft and active instances can have different operation contexts but still require consistent authorization.
A worked example
A travel app lets employees read their own travel requests and managers read their team's requests. DCL filters read visibility. Create permission is global for employees. Update/delete/approve depends on each request's owner/status and is implemented as instance authorization. The UI disables Approve for unauthorized rows, but a direct OData action call is still rejected by backend authorization—proving UI feature control is only convenience, not security.
How to choose
- Use DCL for row-level read access where CDS semantics fit.
- Use global authorization for operation permissions not dependent on an entity instance.
- Use instance authorization when permission depends on object data/status/organization.
- Keep UI feature control and security authorization separate.
- Batch-read authorization-relevant instance data to avoid N+1 checks.
Common pitfalls
- Hiding an action button without enforcing backend RAP authorization.
- Using only DCL and assuming update/action permissions are automatically covered.
- Performing one database read per requested instance in authorization code.
- Returning success for unauthorized keys because one key in the request is allowed.
- Testing with a developer role broad enough to mask failed authorization design.
ECC, S/4HANA and clean core
RAP authorization is the strategic model for ABAP RESTful business objects in S/4HANA/ABAP Cloud. It integrates with CDS/DCL and backend roles while fitting clean-core released service development. Exact behavior-definition syntax/framework method signatures evolve by platform version; use current ABAP documentation for the target release.
Whose problem this is
RAP developers implement checks; Security architects define authorization objects/roles; functional owners define business rules such as status/ownership scope; Fiori developers consume feature/authorization metadata without replacing backend enforcement.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/rap-authorization-global-instance-dclERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.