To describe how to implement virtual authorizations using the BADI
This BAdI interface enables users to generate virtual analytics security objects (ASOs). These ASOs are generated at runtime and are checked as analysis authorizations.
It is therefore only possible to determine which authorizations the user has, at runtime. You can also enhance existing authorizations. Furthermore, you can use variables in virtual authorizations; these variables are then processed as normal customer exit variables as usual at runtime. For reasons of clarity, however, we do not recommend this since the required runtime operations could be executed during the implementation for the virtual ASOs.
Virtual authorizations (analytics security objects) can often actually replace variable processing in authorizations and can therefore make the process flow clearer.
Method GET_AUTHS requests for the content as value authorizations and hierarchy authorizations in parameters C_T_HIE and C_T_VAL. These tables contain the ASO or authorization names and the relevant InfoObjects along with an authorization definition in the form of intervals (C_T_VAL) or hierarchy nodes with the authorization definition (C_T_HIE). One row is expected for each interval and each hierarchy node. The various authorization combinations are grouped together as rows for each authorization (TCTAUTH field). (See example.)
The method can be called in two ways; with or without InfoProviders:
If the InfoProvider is specified in parameter I_INFOPROV, only the authorizations for this InfoProvider are required. If the InfoProvider is not specified, InfoObject I_IOBJNM should generally be used if the module is called in the standard environment for a query. Both parameters can only be initial in the case of documents that are protected with authorizations. InfoProvider-independent, that is, cross-InfoProvider authorizations are then required. Since authorization-relevant attributes are generally specified for a particular InfoObject, these attributes are automatically entered in the input parameter I_T_ATR for the sake of simplicity and to accelerate processing. They can then, for example, be authorized explicitly (I CP * in C_T_VAL), or not authorized, if required.
The user name is also provided when a transaction is started with the function Execute as Other User (RSUDO); the user name does not have to match the value for sy-uname. This means the analysis authorization check is made with a user that differs from sy-uname. You should therefore always use parameter i_uname instead of sy-uname.
Two virtual ASOs, 'ONE' and 'TWO', are to be created. In the first ASO, the interval [A, D] is to be authorized for characteristic 0EMPLOYEE, which is authorized for a specific cost center node. In addition, the combination [D, G] is to be authorized for another cost center.
This is to be done as follows:
Field in C_T_VAL:
TCTAUTH ONE TWO
TCTIOBJNM 0EMPLOYEE 0EMPLOYEE
TCTSIGN I I
TCTOPTION BT BT
TCTLOW A D
TCTHIGH D G
Field in C_T_HIE:
TCTAUTH ONE TWO (Name of authorization or ASO)
TCTIOBJNM 0COSTCENTER 0COSTCENTER
HIESID 123 123 (Field can be left empty)
HIEID AXYDGFHE... AXYDGFHE... (Field can be left empty)
TCTHIENM MYHIERARCHY MYHIERARCHY
TCTHIEDATE 99991231 99991231
TCTNIOBJNM 0HIER_NODE - (Empty means end node or leaf)
TCTNODE 100_all 100123
TCTATYPE 2 1 (Authtype; Authtype = 0 never permitted for leaves (only nodes))
TCTACOMPM 0 0
TCTTLEVEL 2 0
TCTHDATE 00000000 00000000
To find out what is used for interval and hierarchy authorization definitions, see database tables RSECVAL and RSECHIE.
Function module RSEC_GET_AUTHREL_INFOOBJECTS can be used to identify which InfoObjects are relevant (see the documentation for the module).