Kontakt

Ansicht
Dokumentation

ABENBDL_AUTHORIZATION - BDL AUTHORIZATION

ABENBDL_AUTHORIZATION - BDL AUTHORIZATION

ROGBILLS - Synchronize billing plans   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.
SAP E-Book

- authorization

Declaration on entity level

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

RAP BO operation additions, declaration in the entity behavior body

... authorization:none

... authorization:update

Variants:

1. ... authorization master (  )

2. ... authorization dependent by _Assoc

3. ... authorization:none

4. ... authorization:update

Effect

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.

  • instance
  • Authorization check that is dependent on the state of an entity instance.

  • 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 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 for each RAP BO operation if there are any access restrictions.

Unmanaged RAP BO

In an unmanaged RAP BO, and if global authorization control is specified, the RAP framework checks for each RAP BO operation for are any access restrictions.

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 CDS BDL - authorization, projection BDEF.

  • Development guide for the ABAP RESTful Application Programming Model, section Authorization Control.

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.
  • Authorizations can also be checked in other ABP methods, for example, in validations.
  • In UI scenarios, authorization control is displayed as RAP consumer hint.

Example - 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.

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.

The program DEMO_RAP_MANAGED_AUTHORIZATION 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 deleting this instance.
  • 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@@

Example - 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.

The implementation in the ABAP behavior pool specifies that update requests are generally authorized and delete requests are generally unauthorized.
This example is simplistic. A realistic implementation requires a user-dependent authorization concept, for example, based on authorization objects.

The program 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.

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

Variant 1

... authorization master( )


Effect

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).

Variant 2

... authorization dependent by _Assoc


Effect

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 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 syntax_short_form.

Variant 3

... authorization:none


Effect

Can be used as RAP BO operation addition to exclude the operation in question from authorization checks. See CDS BDL - authorization:none.

Variant 4

... authorization:update


Effect

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 CDS BDL - authorization:update.






BAL_S_LOG - Application Log: Log header data   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.

Length: 19486 Date: 20240426 Time: 225128     sap01-206 ( 219 ms )