Preventing Unauthorized Access to Data


After completing this lesson, you will be able to:

  • Create authorization fields and authorization objects
  • Implement CDS access controls

Authorization Objects and Authorization Fields

When you develop a data model, you should also think about how to protect the data against unauthorized access. Earlier in this learning journey, you learned that authorization objects form the basis for user specific, role-based authorization control. To protect your data against unauthorized write access, authorization checks are implemented in the ABAP code using keyword AUTHORITY-CHECK. To prevent unauthorized read access, the use of CDS access controls should be the first choice.

An authorization object groups up to ten authorization fields that are related and should be checked together. Authorization fields are separate development objects. The same authorization field can be referenced by more than one authorization object.

Authorization fields are typed with data elements. The data elements, or the domains they use, usually provide the connection between the authorization fields and the data they protect.

Whether your data model requires its own authorization object(s) or whether you use existing ones, strongly depends on how independent your data model is from existing data.

If your data is connected to existing data models, it is always worth searching for existing authorization objects.


Start the search using the where-used list for the data elements you use in your database tables to see if there are related authorization fields.

Usually, before you create a new authorization object, you create one or more new authorization fields, first.

The authorization field name is limited to 10 characters.

Note that you have to specify an existing data element right from the start. In this example, authorization field Z00DEPMENT is created using data element Z00_DEPARTMENT_ID.

In the maintenance dialog for the authorization field, it is recommended that you specify a Check Table. The check table is a database table that contains the values that are allowed for the authorization field. Depending on your data model, this will be a customizing table or a table with master data. In the example, we use the master data table for departments.

For a newly created authorization field, a warning in the header or on the problems view tells you that the authorization field is not yet used. Links in the What's next? section serve as quick fixes for this warning. Here, you can add the authorization field to an existing authorization object, or create a new authorization object for it.

When you create a new authorization object, you have to provide a name and a description as usual. This name is also limited to 10 characters.


The Object Class defines groups of authorization objects. Whether you can assign an object class or not, depends on the platform on which you develop. On SAP BTP, ABAP Environment, there is currently only one Object Class (CPAE) for all authorization objects.

Any new authorization object contains authorization field ACTVT by default. This field is used to distinguish between various data operations with standardized values.

By default, the authorization object considers activities Create (value "01"), Read (value "03", Update (value "02"), and Delete (value "06"). You can remove activities you do not need, and add more from a large pool of available activities. Place the cursor in the input field and press Ctrl + Space to display the list of available activities.


In rare situations you can even completely remove authorization field ACVT. This should only be done if the authorization check is independent from the performed operation.

To add more authorization fields, place the cursor in the input field and press Ctrl + Space to display the list of available authorization fields.


Neither authorization fields nor authorization objects have to be activated. It is sufficient to save them.

How to Create an Authorization Object

Play the video to see how to create an authorization object.

Repository Object CDS Access Control

Earlier in this learning journey, you learned that CDS access controls are used to filter data sets based on authorizations. Let us recap the basic principle:

A repository object of type CDS access control defines a CDS role using keyword DEFINE ROLE. Within the role, keyword GRANT SELECT ON relates the CDS role to a CDS entity - for example, a CDS view, and after keyword WHERE, it defines one or more access conditions. Whenever ABAP code accesses the CDS entity, the database interface filters the selection result according to these access conditions.

CDS access controls only have an effect when the CDS entity is accessed from ABAP code directly. They are ignored if the CDS entity is accessed indirectly, for example, through another CDS entity.

Let us look at this example: CDS access control R_EMPLOYEE contains the definition of CDS role R_Employee. It restricts access to the CDS view entity, R_Employee, with an access condition based on user authorizations (PFCG condition).

Access Conditions

CDS access controls support various types of access conditions. The most important access conditions are as follows:

Literal Conditions

A literal condition - also known as a simple condition - compares an element of a CDS entity with a fixed value. Literal conditions are the simplest form of access conditions. They do not depend on the current user. As a result of that, they are usually combined with other types of access conditions.

PFCG Conditions

A PFCG condition - also known as a PFCG Aspect - associates elements of a CDS entity with authorizations in the SAP authorization concept (which are based on authorization objects). PFCG conditions are the most common access condition for CDS entities that read directly from database tables.

Inheritance Conditions

An inheritance condition applies the conditions from another CDS role. Inheritance conditions are the usual access condition for CDS views that read from other CDS entities (View on View).

Let us have a look at some examples for simple conditions.

The first example is a literal condition. It specifies that the value of view element DepartmentId has to equal 'ADMIN' or, in other words, that a read access to the related CDS entity only returns data sets that belong to department ADMIN.

The second example is also a simple access condition, but not a literal. The access condition links view element CreatedBy to the user name of the current user. A read access to the related CDS entity only returns data sets the current user created himself.

The third example illustrates that you can use logical operators AND and OR to combine different access conditions. Here, the conditions are connected with OR, meaning that users can see all data sets they created themselves, no matter the department to which they belong. From the data sets that were created by other users, they can only see those that belong to the department ADMIN.


When you create a CDS access control based on template Define Role With Simple Condition, you get the basic structure for one literal condition and one user aspect condition.

Examples: PFCG Conditions

CDS roles with only simple access conditions are not very common. If used at all, simple conditions are combined with other access conditions - for example, PFCG conditions. PFCG conditions link one or more view elements to the authorizations in the master data of the current user.

Play the video to see an example of a CDS role with PFCG conditions and Inheritance Conditions.

CDS Access Control Creation

To create a new CDS access control, proceed as follows:

  1. In the Project Explorer, locate the data definition that contains the definition of the CDS entity for which you want to provide access rules.
  2. Right click the data definition and choose New Access Control.
  3. As you create the access control for a specific CDS entity, the Protected Entity input field already contains the name of this CDS entity. Enter a name and a description for the new access control and choose Next.

    It is strongly recommended that the access control and the protected entity have the same name.

  4. Depending on the required type of access condition, select one of the templates starting with Define Role. Then choose Finish.

Annotation AccessControl.checkAuthorization

When you create a CDS view entity, you can use the @AccessControl.authorization annotation to control whether an access control, can, should, must, or must not exist for this view.

Possible values are as follows:


If a CDS role protects the view, it is evaluated at runtime. The syntax check does not check whether a CDS role exists or not. This is the default value.


Like #NOT_REQUIRED, but with a syntax check warning if no CDS role protects the view.


Like #CHECK, but in addition, the system raises a runtime error if no CDS role protects the view.


No access control is performed. If a role is assigned to this view, a syntax warning occurs and the access control is ignored at runtime.


The CDS entity should be accessed using the ABAP SQL addition WITH PRIVILEGED ACCESS. For detailed information, see SAP note: 2725274.

How to Implement a CDS Access Control

Play the video to see how to implement a CDS access control.

Log in to track your progress & complete quizzes