Analysis Authorizations – Design

The idea for this article came to me after reading through a question from a visitor to this site. I believe the question is relevant to anyone designing Analysis Authorizations. So even though there are other posts in this blog that talk about how to actually create analysis authorization, this current article is meant to help security consultant in actually applying the concepts while designing security. I will start with reproducing the question below.

Q:  Hi Aninda,

Firstly, thanks for the helpful posts on this site.

I would like to check with you on how the system checks BI auth.
Does it check every possible combination?

For eg: user is assigned with 2 analysis auth as below:
A: plant 1000, purchasing group (PG) 100
B: plant 2000, PG 200

When the user runs a report and fills in the fields with plant : 1000, 2000 and PG: 100, 200,
he/she will actually get no authorization. When I checked the trace, it looks like the system is checking for
1) plant 1000, PG 100
2) plant 1000, PG 200
3) plant 2000, PG 100
4) plant 2000, PG 200

In this case, the authorization failed because there is no such combination for 2 and 3 in my analysis authorization. Appreciate your advice if my understanding is correct and how do we work around this apart from asking the user to run the report separately for plant 1000 and 2000? Thanks.

I will elaborate from my original answer below. Firstly I should re-iterate that SAP does indeed check for the 4 different combinations mentioned , i.e.
1) plant 1000, PG 100
2) plant 1000, PG 200
3) plant 2000, PG 100
4) plant 2000, PG 200

This may be counter intuitive to us from our experience in ECC while looking up data from SAP tables in SE16 or SUIM. However, BI reports only return data when the total result set is authorized. In other words, you need access to all possible combinations for the query to return any data at all. You get everything or nothing 🙂

So the next question that we need to answer is how to give access to plants 1000, 2000 and PG 200, 100?

Here we would need to create two new analysis authorization rather than the ones already in use
Auth 1) Plant 1000, 2000
Auth 2) PG 100, 200

However, these two authorizations end up giving access to the combinations for Plant 1000 PG 200 and Plant 2000, PG 100 in addition to the earlier values. We need to ask ourselves, Is this extra access a problem?

Like most consulting questions, there is no single correct answer to the problem. For some clients this extra access might be okay while for others it might be a strict no. I would start looking at how security is set up in ECC and try to replicate same access in BI. For example, I would think a Buyer in ECC would be assigned to one or more purchasing groups and would be responsible for one or more plants. Its far less likely that a Buyer is assigned to a different purchasing groups for different plants. So the more likely scenario tells me that the extra access with the two new authorizations are perfectly fine and in line with ECC security. However, your client might be using a different configuration for plant and purchasing group security.

In case, the extra security access is not enough, the solution would be to ask the reporter to run the BW query twice. Once for Plant 1000, PG 100 and next for Plant 2000, PG 200.

SAP Tables – S_TABU_LIN

We have already looked at the other SAP authorization objects used to secure tables, S_TABU_DIS, S_TABU_CLI, S_TABU_NAM. We end our discussion on table security with the one remaining object – S_TABU_LIN used for Line Oriented Authorizations. This object can be used to provide row level access control when accessing tables through standard tcodes like SM30 and SM31. I have purposely kept the discussion about this object for the last as its the most complicated to use by far and needs configuration changes in addition to role updates. Also note that S_TABU_LIN is always checked in addition, and not in place of, the check for S_TABU_DIS.

To use S_TABU_LIN in our authorization concept, the first step is to configure a Org Criterion through the SPRO transaction. We can use the org criterions provided by SAP or create our own criteria. The path for configuring org citeria is shown below.

Line Oriented Authorizations
Line Oriented Authorizations

We chose the first of the two options, “Define Org Citeria”. We create a new org citerion called ZMOLGA. The check box, Table-ind should remain unchecked as the new org criteria would only be checked for tables maintained by us and not all tables.

Create new org criterion
Create new org criterion

With the new org criteria selected in the screen, we double click the attributes option. This screen allows us to create the attribute for the org criteria. Further we can set the attribute to be the 1st to 8th attribute. The 1st to 8th attribute are actually the authorization fields present in S_TABU_LIN. Though in the present example we will just create a single attribute and set it as the 1st attribute, SAP allows us to create 7 other attributes for the same criterion.

Define Attribute for Org Criterion
Define Attribute for Org Criterion

Finally with the attribute created we just need to set the tables/views which will be checked for the org criteria. We use the view V_T510F_B in our example. Currently SAP only allows us to enter one table or view per attribute. The direct result of this limitation is that we need to create a new org criterion for each table we want to secure through S_TABU_LIN.

Define Table for Org Criterion
Define Table for Org Criterion

We can now save our entries. The system will prompt for a transport request to contain the changed objects. We have now successfully created an org criterion. However, we still need to activate it before S_TABU_LIN and the org criterion will be checked during table access. Activating the criterion is simple. We just check the box and save our entries.

Activate Org Criterion
Activate Org Criterion

Once this preliminary configuration is done, we are free to use S_TABU_LIN in our roles to secure tables based on the Org criterion. Since our criterion ZMOLGA is based on the MOLGA field of the view V_T510F_B, we can actually restrict access to only certain rows of the table depending on the value of the MOLGA field. For example the authorization below will allow the user with this role to change rows for the V_T510F_B view when MOLGA value equals 10.

Using S_TABU_LIN in roles
Using S_TABU_LIN in roles

It is important to remember that S_TABU_LIN will only be checked for the standard SAP table maintenance transactions. Thus if we have some custom code accessing tables, row level security is not going to work for them. Off course nothing is stopping the developer in adding a authority-check statement for S_TABU_LIN in this case.

RSSM – Reporting Authorizations

In all the previous articles on BW security, we have already looked the current method of BW security through analysis authorizations. However, even now its possible for customers to continue to use the old security concept using reporting authorization objects (customer created authorization objects of the RSR class). Since there are still quite a few installations that continue to run in the old model let us have a brief look at this concept of BW security.

The basic transaction for maintaining BW 3.5 security is RSSM. The initial screen of the RSSM transaction can be divide into two main areas as shown below. The upper area is used to create new authorization objects whereas as the lower area is used to configure the checks for authorization objects for the individual cubes.

RSSM - Initial Screen
RSSM - Initial Screen

It is here that we create the the RSR authorization objects. During creation we have the choice of adding any of the authorization relevant InfoObjects defined in the system. However note that since these are authorization objects ( as opposed to analysis authorizations), maximum number of fields are limited to 10.

RSSM - Create Reporting Authorizations
RSSM - Create Reporting Authorizations

Once created, the second step is to check the relevant authorizations for the individual infocubes. This activity is also performed through RSSM as shown below. Whenever a new Infocube is created in BW, by default all possible authorization objects ( these are the authorization objects which contain any of the InfoObjects defined in the cube) are shown to be checked for it. Its the security administrator’s job to un-check all the unnecessary objects.

RSSM - Check Auth Objects for InfoProviders
RSSM - Check Auth Objects for InfoProviders

Like Analysis Authorizations, checks for reporting authorization which occur during query execution can not be caught through the standard security trace (ST01). We use the transsaction RSSMTRACE to trace security checks for reporting authorization objects. For individual users to be traced, they need to be added to list below. A security trace is generated during query execution for all the listed users. Subsequently the trace can be displayed through the same transaction for analyzing possible security errors.

RSSMTRACE - Troubleshooting Reporting Authorizations
RSSMTRACE - Troubleshooting Reporting Authorizations