Authorization in BI covers a broad range of functions for very different classes of users. BI developers are users who create Info­Objects, InfoProviders, transformation logic, and process chains and coordinate load activity. Power users might be responsible for query design, runtime calculations, information broadcasting, and assigning reporting objects to end users under their area of responsibility. End users or information consumers might just execute a limited number of Web pages using predefined navigation choices, while analysts might need access to information relevant only to a specific train of thought, for some what-if scenario.

You can subdivide these classes of users even more, which is just part of the problem facing the people trying to secure the BI system. Additionally, these professionals face legal and internal control requirements such as Sarbanes-Oxley that ensure BI is not just a free-for-all access to information.

Because it is relatively easy to assign infor­mation consumers to specific areas, the complexity comes in more with the power/analyst types of users. These people constantly change responsibilities in the business and their information needs to evolve with the changes. The right level of information access control is critical. If you provide too much security, then the BI system won’t support good analysis. If you have too little focus on security, then someone might go to jail.

Transaction RSECADMIN, a new authorization tool in SAP NetWeaver 2004s, simplifies complex networks of authorization. I’ll walk you through the technical implementation of this transaction. Remember that even with this simplification, you should limit which objects are deemed sensitive and thus require authorization in the first place. If you choose too many objects, then the administration increases at a very high rate.

Although it is possible to revert back to the older BW 3.x reporting authorization class of authorization objects to control reporting user access to InfoObject level values, neither SAP nor I recommend this. You would only do this if you did not have time to investigate and test this new method during the upgrade process. The new tool is easier to use.

You can find the new analysis authorization toolset by using transaction RSECADMIN or following menu path SAP menu>Business Explorer>RSECADMIN - Manage Analysis Authorizations. Next, I’ll explain the steps for implementing analysis authorizations:

Step 1. Determine your authorization schema to control information access at your company. Decide whether to limit access by InfoArea, InfoCube, or query, or assign the analysis authorizations reporting level to differentiate user access for specific values of InfoObjects on a report.

Step 2. If you need to go to the analysis level for your authorization schema, and you need to do it for many InfoObjects for many users, then go back and review step 1 again. This level of detail, even with a new tool, is a big hassle.

Step 3. Set the InfoObject to be authorization relevant.

Step 4. Using the new analysis authorization tool, create authorizations for the limited number of critical characteristics and key figures defined in step 2.

Step 5. Assign analysis authorizations to users.

Step 6. Test the authorizations created in step 5 to make sure your users can see the data necessary to do their jobs effectively.

I’ll focus on the technical implementation of reporting-level authorizations (step 3 and higher).

Authorization Relevant Setting

To create analysis authorizations, you must set the associated InfoObjects involved to authorization relevant by checking the AuthorizationRelevant check box. In BW 3.x this task was just one step in a longer process. Once the flag was set, it did not affect end users until security administrators performed more steps in the process. In SAP NetWeaver 2004s, however, it’s a different story. Once administrators set the flag, authorizations must be in place to allow access to this InfoObject. In other words, you cannot transport the InfoObject with this setting unless you also transport the associated authorizations.

To make InfoObjects authorization relevant, you must set one of two flags depending on whether you’re using a characteristic or attribute. When dealing with characteristics, you set the AuthorizationRelevant flag in the Business Explorer tab (Figure 1). You can make navigational attributes authorization relevant by checking the AuthorizRelevant flag in the Attribute tab (Figure 2). This allows you to make separate authorization decisions for the 0COUNTRY of the transactional data (InfoCube dimension characteristic) versus the 0CUSTOMER_COUNTRY from the master data (the country attribute of customer).

Figure 1

Set characteristics as authorization relevant

Figure 2

Set authorization relevancy for navigational attributes

A third way to make a characteristic authorization relevant involves characteristic 0TCAKFNM (key figure name). This special characteristic InfoObject actually has key figures as its values. Where 0CUSTOMER might have Ned and Bob and Sally as values, 0TCAKFNM has values such as 0AMOUNT, 0PROFIT, and 0SALES. Setting this characteristic to authorization relevant requires you to set authorizations for specific key figures. I’ll elaborate on this later.

Analysis Authorizations Trace

Before I explain step 4, let’s show user Mr. Grunt trying to run a query and failing. Figure 3 shows a query and the results when Mr. Grunt executes it. Note that the customer is not part of this query, but this is the only charac­teristic Mr. Grunt actually cares about accessing.

Figure 3

Failed access to a query

The obvious result is no access. The reasons are less obvious, but you can uncover them by tracing authorizations using two separate tools, the standard ST01 authorization trace and the new BI analysis authorizations trace (accessed via transaction RSECADMIN). I’ll focus on the analysis authorization trace, which coincidentally is the cause of Mr. Grunt’s problems. Figures 4 and 5 show the path and part of the error log for the trace of Mr. Grunt’s execution in the BI analysis authorization trace. To get to the screen in Figure 4, access transaction RSECADMIN and choose the Execution as… button to choose the user and the query to execute. Figure 5 shows part of the Authorization Check Log. The actual log shows more details.

Figure 4

Analysis tools

Figure 5

Analysis authorization trace

Now you know Mr. Grunt has an author­ization problem. Let’s see what his authorization profile is and what it might be missing to allow him to run the query and see the results. Figure 6 shows the authorization profile for the role Mr. Grunt is assigned. Take special note of the missing BI Analysis Authorizations entry in the middle of the screen. There is no value, which the system indicates by displaying it in yellow. Missing the analysis authorization entry means this profile does not invoke any reporting-level authorizations.

Figure 6

Authorization profile connected to Mr. Grunt

Right below the BI Analysis Authorizations entry are several lines that show the authorizations necessary for Mr. Grunt to be able to execute the query and see the result. What is important to note here is that this authorization profile just covers the normal authorizations, under the Business Information Warehouse class. It does not address the field level controls assigned under the new Analysis Authorizations toolset.

Although there is another way to assign analysis authorizations to a user that I will discuss momentarily, I like to use the above authorization object (BI analysis authorizations in role) as the preferred way. This technique increases the visibility of the assignment. Security team members would at least be aware of some analysis authorizations being assigned. To learn the specific values of this authorization, they still would need to understand transaction RSECADMIN.

Now that you know Mr. Grunt is not allowed to see the data in this query (due to InfoObject level constraints), let’s create the missing analysis authorizations to permit him to access the data. Start in transaction RSECADMIN and access menu path RSECADMIN>Create Authorization. Figure 7 shows the screen that appears after accessing the Authorizations tab in transaction RSECADMIN and then creating a new authorization called ATH_CUST. After selecting one of the characteristics in the list, click on the Details button in Figure 7 to show the allowed values for these characteristics. For example, if this was done for 0TCAIPROV in the second row you would see it has a value of NED* (InfoCubes that begin with NED).

Figure 7

Access transaction RSECADMIN and create authorization ATH_CUST

The characteristics in the first column of Figure 7 are some of the ones needed in this example (more to follow). The top three (0TCAACTVT, 0TCAIPROV, and 0TCAVALID) are three notable characteristics. The first covers the activity that users can perform (display in this case). The second, 0TCAIPROV, covers which InfoProviders users can access. The third characteristic, 0TCAVALID, covers the time frame for when they are allowed to have this access.

Let’s focus on which of these three characteristics allow access to the secured customer CUST_SEC. Figure 8 shows the values for this characteristic permitted by this authorization. The entry 100* in the Technical Character. (from) column allows access to view data for customers beginning with 100. The : in the second row of this column allows access to view data connected to the total of all customers. The # in the third row allows access to view data for records where the customer has the setting blank = unassigned.

Figure 8

Values for CUST_SEC characteristic

I’ll further explain the second setting. The value : tells the system that the user is allowed to see the summary of all cost centers, just not the detail. This means, for example, that he could run the query in Figure 3 as a query by material, indirectly showing the total for all customers. Without the : value for customer, the user would not be able to report on any characteristic in the InfoCube because of the indirect disclosure of the total by customer. The total sales sliced by material is the same as the total by customer.

In addition to specific values of CUST_SEC (customers), an authorization to a hierarchy was also included in this analysis authorization, as Figure 9 shows. The circled settings in the middle of the screen dictate the specific navigation of the hierarchy that is allowed (e.g., from the node US and all the way down, for hierarchies of any version, and any time validity). Click on the magnifying glass icon to the right of Nodes in Figure 9 to see the screen in Figure 10.

Figure 9

Allowed hierarchy nodes for US

Figure 10

Allowed hierarchy nodes for CUST_SEC

Because someone on my server previously made the special characteristic 0TCAKYFNM authorization relevant, I am forced to specifically assign key figures to this authorization. To do this, you must add 0TCAKYFNM, and then select the Details tab. This is necessary as soon as one person in your company decides to authorize on one key figure (such as profit). In my opinion, it is very common that someone can see sales but not profit. In my example, I can let Mr. Grunt look at any key figures he wants by assigning an asterisk in Figure 11. If I had limited his authorization to sales, then Figure 11 would show the sales key figure, maybe 0AMOUNT, but not 0PROFIT, in the Technical Character. (from) column instead of *.

Figure 11

Authorization for all key figures = *

This completes the analysis authorization process. Next, I need to assign it to the appropriate users, in this case Mr. Grunt. Again, my preferred way is to assign this via the standard authorizations in a profile connected to a role.

I have created a new role called SUPER_GRUNT. As you can see in Figure 12, the profile for this role just needs the authorization object BI Analysis Author­izations in Role with the value being the analysis authorization I just com­plete­d (ATH_CUST). ATH_CUST is the link from the normal transaction PFCG type authorizations to the analysis authorizations. This role is then assigned to Mr. Grunt in the normal manner. This is done using normal role maintenance (transaction PFCG).

Figure 12

The profile for SUPER_GRUNT with the link to the analysis authorization

It is possible to keep role maintenance (transaction PFCG) completely out of the picture when assigning analysis authorizations to users. You might consider this option only if the authorization department wants to manage using just transaction RSECADMIN or give the maintenance authority to the BI team. If your company embraces this approach, it would streamline the whole process by eliminating the role maintenance step. That would only be needed for the warehouse class of objects.

The assignment technique not involving transaction PFCG and role maintenance is an option under transaction RSECADMIN. It would not make sense to use both assignment tools. Figure 13 shows assignment of analysis authorizations without transaction PFCG using only the Assigned Authorizations section of the Manual/Generated tab of transaction RSECADMIN.

Figure 13

Assignment of authorizations to users using transaction RSECADMIN

Now Mr. Grunt is set up to see the data he asked for. Let’s see if it worked. Figure 14 shows the results for an even more complex query using the aforementioned hierarchy. Figure 15 shows a simple query for customer 1000. These queries show the effects of Mr. Grunt’s new power.

Figure 14

Query using hierarchy

Figure 15

Query using customer 1000

Although Mr. Grunt now has some power, if he tries to access some other information about this query he will be denied, reminding him that he is still a grunt.

Ned Falk

Ned Falk is a senior education consultant at SAP. In prior positions, he implemented many ERP solutions, including SAP R/3. While at SAP, he initially focused on logistics. Now he focuses on SAP HANA, SAP BW (formerly SAP NetWeaver BW), SAP CRM, and the integration of SAP BW and SAP BusinessObjects tools. You can meet him in person when he teaches SAP HANA, SAP BW, or SAP CRM classes from the Atlanta SAP office, or in a virtual training class over the web. If you need an SAP education plan for SAP HANA, SAP BW, BusinessObjects, or SAP CRM, you may contact Ned via email.

You may contact the author at ned.falk@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.