Most flexible Analysis Authorization: The combination of a self-service maintenance of characteristic values and associated key figures to users with an automated and by runtime created "Virtual Analytics Security Object (ASO)" for the Query user allows either to reduce implementation time for authorization projects or especially reduces intensively the creation and maintenance time of user profile assignemts for new and changing security demands. The two aspects include the following:
Both aspects will be covered within this BLOG.
Many thanks and appreciation to my current/last customer project - in person the SD/BI Developer Matthias Hommer - who felt confident either with the concept or the development/implementation to this new approach.
Following picture represents the data model which will be explained with possible alternatives:
On the left hand side of the picture the basis to store user authorization values is displayed. On the right hand side you can see the aspects for virtual analysis authorization on query execution runtime.
Following the principles of "data ownership" (by departement), "self-service BI administration szenarios" and "zero administration" the idea is to let a few key users of each department maintain the authorization values for each of their query users directly into the system. In detail they have to maintain following:
From our perspective there are multiple ways how you can enter and store this data:
To us all of the mentioned possibilities were not appropriate or had some minor / major disadvantages so we decided to use a different approach. Here some arguments we had: by using XLS or CSV you have a break within the media; Dynpro programming seemed to be too complex to us for a hand ful of fields; with InfoObject master data maintenance we did not want to shift authorization to the backend as an other area even for the key users; the concept to use a transactional InfoProvider needs to create (via exit) all possible characteristic value combinations to let the necessary key figure become by default 0 (= not authorized) or via planning query to modify the value combination to 1 (= authorized) by the key user ... also complex.
We have decided to use following - see "I" within the picture above:
Comparing
--> only the authorization values for one single user at one processing time of a Query execution will be processed.
Due to the fact of having a kind of "performance pressure" the alternatives tend to reduce processing time of creating and checking the ASO to each Query execution of a user. Possible is to read the authorization values faster by indexing the DSO's into the BWA (possible with BWA7.20). Also to consider is having instanced the reading of the authority values by the BAdI enhancement implementation already.
In our implementation and system environment we have not many (concurrent) users. So it would be very interesting how virtual ASO's will perform with hundred's or even thousands of Query execution users.
Our implementation is based on a customer class library - please see representing "A" within the picture. Here we combine as well as transformation coding encapsulation like start-, end- or field-routines or Query variable exit coding or other pieces of helping coding within the overall BW environment.
From my personal point of view this new BAdI interface is exciting - it is just great when thinking of all these authorization projects out there and also how much work it is to maintain permanent shifting authorization rights for Query users out there. The combined approach seems to me a tremendous work load rejection of any BI- or system-administration-security team. Please feel free to comment or enhance this idea and/or implementation or give suggestions to similar ideas!
Description
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.
Use
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.
Example
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
TCTHIEVERS
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
Notes
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).
Use
You can use this enhancement to check the execution authorization by implementing your own method instead of using authorization object S_RS_COMP (method get_execution_auth).If an implementation is active, the method of this implementation is checked instead of authorization object S_RS_COMP.If either of the two mechanisms permits execution, the query can be executed.See the technical documentation on implementation.The return value of the method is a boolean value with two possible values:True (=X): Execution authorization exists: A standard check is not performed.False (=empty/initial): No execution authorization by BAdI. -> There is also a standard check for S_RS_COMP.Execution authorization for one of the two mechanisms is therefore sufficient to execute the query (OR logic).
This also guarantees that a user with a SAP_ALL profile can always execute the query, even if the BAdI is not active or returns "no authorization".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
8 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 |