ABAP - BOPF Authorization

Table of contents

• Preparation
• Implementation
• Activation
• Conclusion

The developer help in the BOPF describes two ways to create your own authorization check, first with the class /BOBF/CL_LIB_AUTHCHECK_W_QUERY or with completely new implementation of your own logic with the abstract class /BOBF/CL_FRW_AUTHORITY_CHECK. Today we show you the complete route via the abstract class, in which you implement your own authorization checks.

 

Preparation

The class for checking the authorizations must be created ourselves, since we are working with inheritance and have to do some rework on the new class. Name, description and parent class must be entered, the rest can remain on the standard settings.

 

You should redefine the methods CHECK_AUTHORITY and CHECK_AUTHORITY_STATICALLY in the first step, but you can leave them empty. The method GET_QUERY_CONDITION_PROVIDER should also be redefined and requires implementation. In the following coding you will get a sample coding of how such an implementation can look like. The configuration is read there and a provider for the node and objects is created. Without the implementation of the method, an error occurs when performing operations on the business object.

 

DATA(lo_conf) = /bobf/cl_frw_factory=>get_configuration( zif_tst_bopf_c=>sc_bo_key ).

lo_conf->get_node(
  EXPORTING
    iv_node_key = is_ctx-node_key
  IMPORTING
    es_node     = DATA(ls_node_conf)
).

ro_provider = /bobf/cl_sadl_auth_cond_provid=>get_instance(
  EXPORTING
    iv_anchor_entity = /bobf/cl_sadl_entity=>get_entity_id_by_bo_node_name(
                          EXPORTING
                            iv_bo_name   = CONV #( lo_conf->ms_obj-bo_name )
                            iv_node_name = CONV #( ls_node_conf-node_name )
                       )
    is_customizing_context = is_ctx
).

 

 

Implementation

During the implementation, we use the dynamic check on values of the instance, i.e. we implement the CHECK_AUTHORITY method. The method has the following interface, which we can use:

 

Accordingly, the context of the request is available to us, with which we first check whether the correct node has been selected. BOPF checks the authorizations for all nodes, but our check should only work specifically for the head entry. If this is successful, we read in the data for the node and check the data against an authorization object. Faulty nodes are taken over by the return table ET_FAILED_KEY so that these data records are filtered out. An implementation could therefore look like this:

DATA:
  lt_head  TYPE ztest_t_contract.

IF is_ctx-node_key <> zif_tst_bopf_c=>sc_node-contract.
  RETURN.
ENDIF.

eo_message = /bobf/cl_frw_factory=>get_message( ).

io_read->retrieve(
  EXPORTING
    iv_node       = is_ctx-node_key
    it_key        = it_key
    iv_fill_data  = abap_true
  IMPORTING
    et_data       = lt_head
).

LOOP AT lt_head REFERENCE INTO DATA(lr_head).
  " Do Authority Check

  IF sy-subrc <> 0.
    INSERT VALUE #( key = lr_head->key ) INTO TABLE et_failed_key.
  ENDIF.
ENDLOOP.

 

Activation

However, your own authorization check must first be activated before it run automatically. For this, the checkbox "Business Object has authorization checks" must be activated in the header of the business object.

 

This unlocks additional options and fields on the nodes. The checkbox "Node has own checks" and the deposit of the class then, activate the checks. Then the authorization for the respective node is checked with each access.

 

Conclusion

Some additional steps are necessary to implement your own authorization checks, but these are quickly explained and carried out. With our tip, you will be able to quickly implement customer requests and check specific custom authorizations.