0INFOPROV vs 0TCAIPROV

I recently faced an authorization issue when a new BW/BEx report was created. It wasn’t accessible by end users. When I traced in t-code RSECADMIN I got below error message:

Authorization missing for aggregation (":"): Char: 0INFOPROV – empty

From the trace itself, it looked like it is obvious. Analysis authorization object used in role of end user lack a 0INFOPROV characteristics. In particular its column aggregation. I followed up my analysis by checking corresponding analysis authorization object.

By definition (see e.g. here) every analysis authorization object needs to have below three characteristics:

0TCAACTVT (activity), 0TCAIPROV (InfoProvider) and 0TCAVALID (validity)

 

Therefore, no mention of the 0INFOPROV that popped up in the RSECADMIN’s trace. From this, it seemed that my analysis authorization object is setup in correct way. Nevertheless, why the RSECADMIN’s trace is complaining about 0INFOPROV? What is relation between the 0INFOPROV and 0TCAIPROV? The latter is referenced to earlier one. However, that shouldn’t matter...

It turned out that the 0INFOPROV was set to be an Authorization Relevant (in table RSDCHA field AUTHRELFL is set to X). As you can see on below picture, the 0INFOPROV comes from a Business Content as not Authorization Relevant (tables in both systems) however in the SAP BW system in question (table at the picture’s bottom) the active version of the characteristics was enabled as Authorization Relevant. That particular setting was driving the security trace to mark the 0INFOPROV as not present in the analysis authorization object. Once I included the 0INFOPROV (and its column aggregation) into the analysis authorization object effected, business user was able to access the report.

More information:

Defining Analysis Authorizations

820183 - New authorization concept in BI

1956404 - Characteristics 0TCAIPROV, 0TCAACTVT, 0TCAVALID are no longer Authorization Relevant after Upgrade to BW7.3 or higher

Authorization relevant t-codes in SAP BW

Here’s a brief overview of BW authorization / security relevant t-codes.

Transaction Code     Short text

RSECADMIN            Manage Analysis Authorizations

RSECAUTH               Maintenance of Analysis Auth.

RSECAUTH02           Mass Maintenance - Analysis Auths

RSECENVI                Assignment Environment Authorization

RSECPROT               Maintenance of Analysis Auth.

RSECSY                   Mass Maintenance - Analysis Auths

RSU01                     User Maint. BI Analysis Auth.

RSUDO                    Execution as Other User

RSUDU                    Execution as Other User

More information:

2182164 - RSECADMIN Overview [VIDEO]

OLAP Authorizations wiki

1234567 - The authorization log RSECADMIN

2552884 - HowTo: Bex query authorization analysis - decision tree

177875 - Authorizations for investigation of OLAP problems

2044628 - How to record and save an OLAP authorization trace using transaction RSECADMIN

Few remarks on usage of RSUDO / RSECADMIN t-codes

Suite of t-codes like RSECADMIN (central t-code Analysis Authorization management) and RSUDO (Execution as Other User) are very important while analyzing issues of production queries. Very important is feature of the RSUDO (btw it is very smart name of the t-code, similarly like on OS level – execute something on behalf of other user) which simply executes the BW report on behalf of other user.

Normally we can expect that while user A executes particular query on behalf of other user (let’s say user B) the query result should be the same as the same query is executed by user B directly.

However, such an assumption might be wrong. Especially it can be wrong on cases in where customer exit variable is used in the query definition or in user's authorization definition. Other case can be while a system variable sy-uname is used in customer exit variable coding.

Reason is that value of variable sy-uname can’t be converted in case one user executes the query on behalf of other. The system cannot change the sy-uname variable. Thus the A value of the sy-uname is in place for user A and B value for the same is in place for user B.

One of the solution how to avoid such a situation is to avoid usage of sy-uname in the customer exit coding. This can be done at least for cases when variable is used in the query definition or in user's authorization definition. By leveraging function module  RSEC_GET_USERNAME in coding a proper user name (the one of which analysis authorization should be evaluated ) can be retrieved.

See also help pop-up in t-code RSUDO available under button “How does this work”.

More information:

1914703 - Transaction RSECADMIN "Execute as User" has different BW query result compared to direct BW query execution result by this user

Special characters in Analysis Authorization values

First a brief info on what Analysis Authorization is.

Analysis Authorizations (AAUT) is concept used in BW systems to grant an access to the data in the system for users. This AUT concept is not based on the standard authorization concept of SAP as it is used in SAP transactional systems like ECC. The AAUT concept serves the purpose of users that access query data.

Unlike standard authorization concept of SAP which is based on classic authorization objects the AAUT concept is based on so called Analysis Authorization object. Such an object includes a group of characteristics and there are values defined for these characteristics which an access will be granted to. The AAUT object (or so called authorization objects for reporting) can include any characteristics that are flagged as authorization-relevant characteristics. This flag is available on maintenance screen of the characteristics in RSA1 -> Modeling -> Business Explorer -> Authorization Relevant. Once the flag is enabled AAUT objects for reporting can be generated for the characteristic.

While BW report or query is running by user the system selects the data from infoprovider. Once there is an authorization relevant characteristics part of the data set the system evaluates whether user has enough authorization for the whole data set. Only in case use fulfills the AUT values they the data is displayed.

The AAUT objects are maintained in tcode RSECAUTH (you can jump there also via tcode RSECADMIN). One AAUT object can have multiple characteristic included and each of them can have multiple values against which an access is evaluated. Basically the values can be of two types: flat values or hierarchy values. All operators like EQ, BT, GT, LE etc. are possible.

Now let’s see what different flat values that can be entered here are. Except regular values where the value is precisely spelled out there can be also following ones:

* (asterisk): represents any number of characters

+ (plus): represents exactly one character

: (colon): authorization for aggregated values, serves for purposes of displaying aggregated values (e.g. totals), in case there are two characteristic values tied to different key figures and user is only authorized to see the data for characteristics of one value having Colon in the AAUT object will enable the user to see the total coming from both values of the characteristic.

$ (dollar sign): enables usage of BW variables of type customer exit in authorizations, the variable name is introduced by dollar sign.

Few examples:

I EQ      02                                   //fixed value

I EQ      0TCT_24                           // fixed value          

I CP      A*                                   // patter                

I EQ      $VAR_SECT                       //variable

I EQ      :                                     //for aggregated values