What does it do? 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 must be implemented in the ABAP behavior pool. In the ABAP behavior pool, there are different methods for implementation for global and for instance authorization. The following variants are available:
global
Limits access to data or the permission to perform certain operations for a complete RAP BO, independent of individual instances, for example , depending on user roles.
Can be specified for the following operations of an entity: create, create by association, update, delete, static actions, instance actions.
Must be implemented in the RAP handler method FOR GLOBAL AUTHORIZATION.
instance
Authorization check that is dependent on the state of an entity instance.
Can be specified for the following operations of an entity: create by association, update, delete, instance actions.
Must be implemented in the RAP handler method FOR INSTANCE AUTHORIZATION.
global, instance
Global and instance authorization control can be combined. In this case, instance-based operations are checked in the global and in the instance authority check. Both RAP handler methods, FOR GLOBAL AUTHORIZATION and FOR INSTANCE AUTHORIZATION, must be implemented. The checks are executed at different points in time during runtime. authorization master and authorization dependent are defined on entity level in the entity behavior characteristics for each entity behavior definition separately. Currently, only RAP BO root entities can be authorization master entities. If a root entity is defined as authorization master entity, then it is recommended that each child entity that is behavior-enabled is defined as an authorization dependent entity. Authorization checks must be implemented in the ABAP behavior pool. This can be done, for example, using authorization objects.
Managed RAP BO In a managed RAP BO, if the root entity is specified as authorization master, the RAP framework checks each RAP BO operation for any access restrictions.
Unmanaged RAP BO In an unmanaged RAP BO , and if global authorization control is specified, the RAP framework checks each RAP BO operation for any access restrictions. ABAP_CAUTION If instance authorization control is specified, this is not the case. The RAP framework does not call the method for instance authorization in unmanaged non-draft scenarios. If authorization control is relevant, it must be implemented in the respective method for each modify operation. Only in UI scenarios, the instance authorization control method has an effect on the RAP consumer hints.
Draft-enabled RAP BO In a draft-enabled RAP BO, the RAP framework checks for each standard operation on a draft instance whether there are any access restrictions. For the draft actions Resume and Edit, the authorization control for create is checked. For the draft actions Activate, Discard, and Prepare, the authorization methods are not called. To prevent a draft instance from activation, the authorization check has to be implemented in a validation.
Projection BO In a projection business object, the authorization from the base business object is automatically inherited. If new actions or functions are defined in the projection layer, a new authorization control for these actions and functions can be defined. For further details, see topic TITLE .
ABAP_FURTHER_INFO
Development guide for the ABAP RESTful Application Programming Model, section Authorization Control.
Latest notes:
If BDEF strict mode is enabled, it is mandatory that each entity is marked either as authorization master or as authorization dependent.
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. NON_V5_HINTS ABAP_HINT_END
ABAP_EXAMPLE_VX5 - Managed, Instance Authorization The following example shows a managed BDEF based on the CDS root view entity DEMO_RAP_MANAGED_AUTHORIZATION . The root entity is defined as authorization master for instance authorization control. BDEF DEMO_RAP_MANAGED_AUTHORIZATION The implementation in the ABAP behavior pool specifies that delete operations are not allowed if an instance has the value B in the field DataFieldRoot. METH BP_DEMO_RAP_MANAGED_AUTHORIZAT(CCIMP)=>GET_INSTANCE_AUTH The class CL_DEMO_RAP_MANAGED_AUTHRZTN accesses the business object using EML and performs the following actions:
It creates two instances of the root entity. One of them has the value B in field DataFieldRoot and therefore the instance authorization control does not allow this instance to be deleted.
It tries to delete both entity instances. For one instance, the delete operation is successful. For the second entity instance, the delete operation is prevented by the authorization check. An error message is returned. Result: For one entity instance, the delete operation fails. An error message is returned. IMAGE ABDOC_AUTH1.jpg 394 361 ABAP_EXAMPLE_END
ABAP_EXAMPLE_VX5 - Unmanaged, Global Authorization The following example shows an unmanaged BDEF based on the CDS root view entity DEMO_RAP_UNMANAGED_AUTH. The parent entity is defined as authorization master for global authorization control and the child entity is defined as authorization dependent entity. BDEF DEMO_RAP_UNMANAGED_AUTH The implementation in the ABAP behavior pool specifies that update requests are generally authorized and delete requests are generally unauthorized. ABAP_NOTE This example is intentionally kept short and simple and serves demonstration purposes only. A realistic implementation requires a user-dependent authorization concept, for example, based on authorization objects. METH BP_DEMO_RAP_UNMANAGED_AUTH(CCIMP)=>GET_GLOBAL_AUTH The class CL_DEMO_RAP_UNMANAGED_AUTH accesses the business object using EML and performs the following actions:
It creates three instances of the parent entity and two instances of the child entity. This is allowed, since no authorization restrictions are implemented for the create operation.
It updates two of the instances of the parent entity. This is allowed, the authorization check is successful.
It tries to delete an instance of the parent entity. This is prevented by the authorization check, since delete operations are forbidden. An error message is returned.
It deletes an instance of the child entity. This request is directed to the authorization master entity and it is interpreted as update request of the authorization master entity. The authorization check is successful and the child entity instance is deleted. ABAP_EXAMPLE_END
ABAP_EXAMPLE_ABEXA The example above is explained in detail in the executable example RAP BDL - global authorization. ABAP_EXAMPLE_END
ABAP_VARIANT_1 ... authorization master( )
What does it do? Declares an entity as authorization master entity. Currently only available for root nodes. An entity is defined as authorization master if the operations of this entity have their own authorization implementation. That means in the behavior implementation of this entity, the authorization control must be implemented in the corresponding method for authorization (global or instance).
ABAP_VARIANT_2 ... authorization dependent by _Assoc
What does it do? Defines an entity as authorization dependent. Modifying requests for this entity are directed to 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. 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 compositions 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 following syntax short form is available to summarize lock dependent, ETag dependent, and authorization dependent: ($[lock$]$[, authorization$]$[, etag$]) dependent by _assoc For details, see topic TITLE .
ABAP_VARIANT_3 ... authorization:none
What does it do? Can be used as RAP BO operation addition to exclude the operation in question from authorization checks. See RAP BDL - authorization:none .
ABAP_VARIANT_4 ... authorization:update
What does it do? Can be used as RAP BO operation addition to delegate the authorization check. An operation specified as authorization:update has the same authorization control that is defined for the update operation. See RAP BDL - authorization:update .
