CDS access controls are defined as CDS roles that leverage the data control language (DCL).
In the ABAP Development Tools (ADT) environment, they are created in a guided dialog similar to the CDS data models. This creation dialog can be opened, for example, by going to the menu and choosing File > New > Other... > ABAP > Core Data Services > Access Control.
In the first step of the creation wizard, you can enter the name (Name) of the DCLS object, its description (Description), and the CDS entity (Protected Entity), which refers to the data that will be protected by the CDS access control. In the example shown below, the name of the DCLS matches the name of the protected CDS entity ZI_SalesOrder.
The subsequent steps are the same as when creating a CDS model. You may also select and apply a suitable template for the access control in the last step of the wizard, as shown in this figure.
Below shows the implementation of the access control immediately after leaving the creation wizard by clicking Finish.
@EndUserText.label: 'Auto assigned mapping role for ZI_SalesOrder'
@MappingRole: true
define role ZI_SALESORDER {
grant select on ZI_SalesOrder
where (entity_element_1,
entity_element_2)
= aspect pfcg_auth(authorization_object,
authorization_field_1,
authorization_field_2,
filter_field_1 = 'filter_value_1');
}
In principle, CDS roles can grant users unrestricted access to the selection results. However, CDS roles usually contain conditions under which the access to the data of the protected CDS models is granted to the users. These access rules may be composed of various access conditions. The latter can be formulated by correlating fields of the CDS models with the logged-on user, with user-specific settings, with constant literal values, or with authorization fields of authorization objects. These authorization objects are the same as those that the Transaction PFCG-based authorization concept is based on.
In the following, we’ll first focus on the usage of authorization objects and fields, which covers the most frequent use cases.
Here, we adapt the access control from before by replacing placeholders like entity_element_1 and authorization_object in the WHERE-condition with CDS view field SalesOrderType and authorization object V_VBAK_AAT.
@EndUserText.label: 'Auto assigned mapping role for ZI_SalesOrder'
@MappingRole: true
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrderType ) =
aspect pfcg_auth ( V_VBAK_AAT,
AUART,
ACTVT = '03' );
}
Therein, CDS role ZI_SalesOrder protects CDS view ZI_SalesOrder from the following.
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_SalesOrder
as select from ...
{
key SalesOrder,
SalesOrderType,
...
}
CDS role ZI_SalesOrder restricts access to the selection results of protected CDS view ZI_SalesOrder based on the order type. For this purpose, field SalesOrderType is linked to corresponding authorization field AUART of authorization object V_VBAK_AAT from the following figure. Accordingly, a user may only access a record of the sales order document via protected CDS view ZI_SalesOrder if the authorization that is granted to that user contains activity ACTVT with value 03 (display authorization) for corresponding order type SalesOrderType.
CDS roles and their corresponding access rules often contain several authorization conditions whose results are logically connected. In this context, the applied conditions may also refer to different authorization objects. Below shows such a complex CDS role definition for CDS view ZI_Sales-Order from before.
@MappingRole: true
define role ZI_SalesOrder {
grant select on ZI_SalesOrder
where ( SalesOrderType ) =
aspect pfcg_auth ( V_VBAK_AAT,
AUART,
ACTVT = '03' )
and ( OrganizationDivision,
SalesOrganization,
DistributionChannel ) =
aspect pfcg_auth ( V_VBAK_VKO,
SPART,
VKORG,
VTWEG,
ACTVT = '03' );
}
In addition to the access condition from before, this role definition contains another condition that is combined with the first condition by a logical AND. This additional authorization condition incorporates additional authorization object V_VBAK_VKO into the CDS access control.
To obtain read access to the data of CDS view ZI_SalesOrder, the user must therefore not only be authorized for the order type (SalesOrderType) via authorization object V_VBAK_AAT but also for the division (OrganizationDivision), the organization (SalesOrganization), and the distribution channel (DistributionChannel) via authorization object V_VBAK_VKO.
Note that within the modeled access condition, CDS view fields OrganizationDivision, SalesOrganization, and DistributionChannel are implicitly mapped according to their order onto the authorization fields SPART, VKORG, and VTWEG, respectively. These bindings are compounded by logical and relationships.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.
Comments