ABAP - Keyword Documentation → ABAP RAP Business Objects → RAP - Behavior Definitions → RAP - BDL for Behavior Definitions → RAP - Managed and Unmanaged Behavior Definitions → RAP - EntityBehaviorDefinition → RAP - EntityBehaviorCharacteristics → 

    RAP - Authorization

    Syntax

    ... authorization master {( global ) 
                             |( instance ) 
                             |( global, instance )} 
      | authorization dependent by _Assoc ...

    Description

    Authorization control in RAP protects your business object against unauthorized access to data. Authorization control is defined in the entity behavior characteristics for each entity behavior definition separately and it must be implemented in the ABAP behavior pool. Different methods are available for implementing different types of authorization control.

    RAP BO entities must be specified either as authorization master or authorization-dependent entities:

    • RAP authorization master entities  have their own authorization implementation in the ABAP behavior pool in the corresponding method for authorization (global or instance). The implementation is used when requesting access to the authorization master entity or to any of its authorization-dependent entities.
    • RAP authorization dependent entities use the authorization control that is defined on the related authorization master entity. Authorization requests are delegated to the implementation of the authorization master entity. For update, delete, and create-by-association operations on an authorization-dependent entity, the authorization check for update of the authorization master entity is applied.

    The following rules apply:

    • Each RAP BO entity must be declared as authorization master entity or as authorization dependent entity using the syntax authorization master (...) or authorization dependent by _Assoc.
    • The RAP BO root entity must be defined as authorization master entity. All other RAP BO entities can be either authorization master or authorization-dependent entities.
    • If the authorization master entity is not the parent entity of the authorization-dependent entity, then the association to the authorization master entity must be explicitly defined in the entity behavior definition using the syntax association _AssocToAuthMaster { }.
    • The authorization control that is defined for a RAP BO entity applies to all RAP BO operations of that particular entity. The following RAP BO operation additions can be used for to control authorization checks for individual RAP BO operations:
    • In the following cases, the authorization control must be implemented in separate methods for authorization in the behavior pool of the authorization-dependent entity:
      • actions of authorization dependent entities
      • create-enabled cross-BO associations
      • create-enabled associations which are not to-child associations

    The following types of authorization control are available:

    Authorization checks can be implemented, for example, using authorization objects.

    Availability

    • Managed RAP BO
    • Unmanaged RAP BO
    • Draft-enabled RAP BO
    • Projection BO
    • RAP BO interface

    Hints

    • The EML statement IN LOCAL MODE can be used to skip authorization control.
    • A RAP BO consumer can use the EML statement GET PERMISSIONS to check whether a RAP BO has authorization control implemented.
    • To limit read access to a business object, Data Control Language (DCL) can be used. These CDS access controls defined in Data Control Language (DCL) are passed on from the base layer to the RAP BO projection and the RAP BO interface. An executable example that demonstrates how read access control is implemented and evaluated can be found in topic RAP BDL - RAP BO with DCL Access Control.
    • Authorizations can also be checked in other ABP methods, for example, in validations.
    • In UI scenarios, authorization control is displayed as RAP consumer hint.
    • In BDEF extensions to managed and unmanaged RAP BOs, authorization control must be specified for each action separately. The reason for this is that the authorization control of extension actions should be independent of the authorization control of the original RAP BO to ensure stability even if the original BO is changed.
    • The following syntax short form is available to summarize lock dependent, ETag dependent, and authorization dependent:

    Further Information

    Executable Example

    The example above is explained in detail in the executable example RAP BDL - global authorization.

    Continue