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

Lesson 4 of 5

Securing data with CDS access control

10 min

Listen to this lesson

0:00 / 14:29

A data model that anyone can read is not finished. In classic ABAP every program had to call AUTHORITY-CHECK itself, and the one that forgot became an audit finding. CDS moves row-level read authorization into the model: CDS access control applies implicit restrictions whenever a CDS entity is read with ABAP SQL, so every consumer gets the same rule. SAP's documentation is clear about one thing you must remember: access control restricts reading. Who may change data is decided elsewhere, for example by authorization control in a RAP behavior definition.

CDS roleDefined with define role in an access control object; @MappingRole: true assigns it to all users
Access rulegrant select on ZI_CMC_CoreAgreement: one rule per protected entity
Access conditionswhere ... : literal, PFCG (authorization object), user-defined aspect, or inheritance
RuntimeEvery ABAP SQL read gets an extra WHERE condition; only permitted rows return
The parts of CDS access control, as SAP describes them.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-201

Writing a role

A CDS role is defined with define role in an access control object, which by convention has the same name as the entity it protects. The annotation @MappingRole: true is mandatory and means the role is implicitly assigned to all users; the actual restriction comes from the conditions. Inside, grant select on names the entity and where lists zero or more access conditions. SAP documents four common kinds: a literal condition compares a field to a value; a PFCG condition looks up the user's authorizations for an authorization object; an aspect condition uses a user-defined aspect based on data in the model; an inheritance condition reuses the rules of another entity.

Contoso needs exactly one rule today. After Wave 2, Alternadores del Norte users in company code 1910 will use the same deposit app, and they must see only agreements for sales organization 1910, while Maria's team sees 1710. Kenji's role protects ZI_CMC_CoreAgreement with a PFCG condition that maps the view's SalesOrganization field to the sales organization field of the standard sales document authorization object, with display activity. Users' existing PFCG roles then decide what they see; nobody has to maintain a second list.

The CDS role turns the user’s existing sales organization authorization into an extra WHERE condition on every read.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-201
Test userSales org authorizationExpected rows in the deposit list
Maria (order-to-cash key user)1710 onlyContoso Motor Co. agreements only
Wave 2 key user in Monterrey1910 onlyAlternadores del Norte agreements only, for example Flotillas Monterrey
Dan (finance process owner)1710 and 1910Both, with USD and MXN amounts
A user with no sales org authorizationNoneAn empty list, not an error

Access test matrix Priya’s team uses for the protected view (users and values illustrative).

Three traps

  • No automatic inheritance. A role protects only the entity it names. A consuming view on top reads unrestricted unless it has its own role or an inheritance condition. Protect each entity that exposes business data.
  • Switched-off checks. @AccessControl.authorizationCheck: #NOT_ALLOWED makes the runtime ignore roles; SAP intends it only for technical data. ABAP SQL with WITH PRIVILEGED ACCESS also bypasses access control.
  • Template default. The template default #NOT_REQUIRED makes access control optional, so a view without a role quietly returns everything.
A role protects only the entity it names: a view on top reads unrestricted unless it has its own role or inherits one.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-201
  1. Does the view expose business data to users?Yes → it needs a role or an inheritance condition · No (technical data) → #NOT_ALLOWED may be justified
  2. Is there a role for this exact entity?Yes → test it with users of each scope · No → write one before release
  3. Does any consumer use WITH PRIVILEGED ACCESS?Yes → document why and review it · No → access control applies
  4. Does a view on top add or remove fields used in conditions?Yes → recheck inheritance · No → the inherited rule still fits
Access control review questions for each new or changed view.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-201

What would you do?

A week before the Wave 2 go-live, a Monterrey key user reports seeing Contoso's US agreements in Dan's new analytical cube, although the deposit list correctly shows only 1910. What is the most likely cause?

Key points
  • CDS access control restricts reading through ABAP SQL; change authorization is handled elsewhere.
  • A role uses define role, @MappingRole: true, grant select on and access conditions.
  • Conditions can be literal, PFCG, aspect or inheritance based.
  • Roles are not inherited by consuming views; protect each entity.
  • #NOT_ALLOWED and WITH PRIVILEGED ACCESS bypass access control; review every use.

Check your understanding · not graded

Lesson check

  1. 1. What does @MappingRole: true mean on a CDS role?

  2. 2. A consuming view is built on a protected view. What access control does it get automatically?

  3. 3. Which access condition type looks up the user’s authorization object values?

  4. 4. Which ABAP SQL addition bypasses CDS access control?