Authorization Overview

Authorization Control in RAP

 

Business applications require an authorization concept for their data and for the operations on their data. Display and CRUD operations, as well as specific business-related activities, are, therefore, allowed for authorized users only.

 

In a transactional development scenario in RAP, you can add authorization checks to various components of an application. In this case, different mechanisms are used to implement the authorization concept.

 

Authorization Checks for Read Operations

To protect data from unauthorized read access, the ABAP CDS provides its own authorization concept based on a data control language (DCL). To restrict read access to RAP business objects, it is sufficient to model DCL for the CDS entities used in RAP business objects. The authorization and role concept of ABAP CDS uses conditions defined in CDS access control objects to check the authorizations of users for read access to the data model and data in question. In other words, access control allows you to limit the results returned by a CDS entity to those results you authorize a user to see.

 

Authorization Checks for Modify Operations

In RAP business objects, modifying operations, such as standard operations (create, update, delete) and actions can be checked against unauthorized access during runtime. To retrieve user authorizations for incoming requests, authority checks are included in the behavior definition and implementation for your business object. In case of negative authorization results, the modification request is rejected.

 

Authorizations for OData Services Consumption

SAP Gateway provides predefined roles as templates for developers, administrators, end users of the content scenarios, and support colleagues. SAP customers will configure the roles based on these templates and assign users to the roles.

 

Overview of RAP Authorization Control

 

The figure, Overview of RAP Authorization Control, shows the main design time components in a transactional development scenario, including the artifacts required for enabling authorization checks at all levels of the application.

 

Normalized views serve as the data source for modeling the data associated with the business object layer. To check the authorizations for read access, corresponding CDS roles are defined in CDS access controls, using the data control language (DCL). A CDS role specifies access rules. Each access rule defines access to the CDS view that the role is assigned to. Different access controls are created for access control at business object data model level (Data Model View in this figure ) and at the consumption level (Projection View in this figure). While the access rules on data model level are usually based on ABAP authorization objects, access controls on consumption level often inherit the rules from the underlying access controls.

 

The behavior definition on data model level, contains the authorization definition. It specifies for which entities of the RAP BO individual authority checks are applied and which of the checks are performed for individual instances. The handler classes in the behavior pool then provide appropriate code exits for implementing the authorization checks, for example with ABAP statement AUTHORITY-CHECK.

 

For developers at SAP, no further steps (concerning authorizations) are required for the resulting OData service to be consumed in the customer's landscape. SAP gateway already provides predefined roles as templates for accessing the OData services and SAP Fiori apps.

 

CDS Access Controls

Creating Access Controls

 

Access controls enable you to filter access to data in the database. If no access control is created and deployed for the CDS entity, a user who can access the CDS entity can view all the data returned.