CDS - Authority check

So far we have mainly talked about obtaining the data and how we make it available to applications and users. At the same time, we haven't given much thought to the actual security concept and how we can actually prevent not everyone from having access to everything. In this article we want to provide you with a first introduction to the topic.

General

The verification of the authorizations for the data of a core data service are largely based on the proven concepts of the SAP system, from the authorization objects. We define a separate authorization object for our checks:

In this case, the authorization object is based on the material number and the activity in order to make restrictions when the material is displayed.

Access control

In order to define an authorization check for an object, we create an access control. This is a new type of object that you can create directly from the Core Data Service context menu:

We then define the content of the authority validation. We allow access to the data if the following conditions are allowed. Since we refer to an authorization object, we use the "pcfg_auth" aspect, i.e. the normal user authorization:

@EndUserText.label: 'Authority check for material'
@MappingRole: true
define role ZBS_I_DmoMaterial {
  grant 
    select
      on
        ZBS_I_DmoMaterial
          where
            ( MaterialNumber ) = aspect pfcg_auth(ZBS_DMOMAT, MATNR, ACTVT = '03');
}

In the where condition, the fields for the comparison are selected (here MaterialNumber) and the fields are checked in the back part. The number of fields selected is distributed in the order of the placeholders of the authorization object. The authorization object follows in the brackets first, then the placeholders, which can also have corresponding test values. In this case MaterialNumber is assigned to the MATNR and compared.

The following checks can be made in the access control:

• Matching an authorization (pfcg_auth)
• Direct restriction via the where condition

Annotation

In the source view, we usually set the "@AccessControl.authorizationCheck" annotation to "#NOT_REQUIRED" so that no authorization check is expected and the compiler no longer indicates that access control is missing. The following characteristics are possible:

• #CHECK - Behaves like NOT_REQUIRED, but the compiler warns the developer that no check has been implemented yet.
• #MANDATORY - Triggers a dump when accessing the CDS view and no access control has been defined.
• #NOT_ALLOWED - Issue warning message when access control is applied.
• #NOT_REQUIRED - If no access control is defined and required.
• #PRIVILEGED_ONLY - Access via ABAP SQL only works if the addition "with privileged rights" is used.

Conclusion

The limitation of authorizations is just as important as the structure of the data model. At the end of the development you should also ensure the protection of your data. Basically, the topic is much more extensive than we have described, it should give you an easy introduction.