Finance, controlling, logistics: As an authorizer, the trade is the same in most modules. However, additional knowledge is required if you want to provide users with reports and analyses from SAP NetWeaver Business Intelligence (BI). We explain how SAP BI authorizations are structured and what you need to keep in mind.
If you want to evaluate company data and make it available in SAP, you can’t get around SAP NetWeaver Business Intelligence (BI). To ensure that users are only allowed to view and edit the reports that really concern them, correct authorizations are also required here. However, BI authorizations are structured differently than in most other SAP modules.
Good to know: If SAP NetWeaver Business Intelligence (BI) doesn’t mean anything to you, you may still know the module under the name SAP Business Information Warehouse (BW). The name has changed, but both mean the same application.
First of all, the familiar procedure: BI authorizations are of course also controlled via roles and authorization objects. But not only. Basically, you need two different types of authorizations:
- Standard authorizations
- Analysis authorizations
Theoretically, all of them could be defined in a single role. However, especially if you work for larger companies, it is recommended to separate the permissions. For example, you can create one
- menu role
- reporting role
- analysis role
and combine them in a composite role. This composite role then contains all the authorizations required to call up one (or more) reports. This way, even if you have a large number of reports to authorize and different user groups, you can keep an overview and track changes more easily.
Menu roles: More convenience for end users
The menu role is quickly explained: It does not contain any authorizations. Instead, the role menu contains all reports that the user should see. Clarify whether you add these reports to the role menu yourself or whether the BI developers replicate them directly into the role via an interface.
Note: The menu role only ensures that the user sees the reports. This does not yet mean that he can also open the reports. For that, he needs the appropriate reporting role.
Reporting roles: Without it you see nothing
The reporting role ensures that users can open reports for which they are authorized. In addition, you restrict here which content should actually be displayed within a report. You can also use the reporting role to make only individual parts of a report accessible.
The most important authorization objects in the reporting role are accordingly:
S_RFC: Necessary to replicate data from other systems. Caution: Do not assign * authorizations for the name and type of RFC objects.
S_RS_AO: Necessary to open workbooks in SAP BusinessObjects Analysis (for Microsoft Office) and to edit or save them if necessary.
S_RS_COMP or S_RS_COMP1: Necessary to authorize access to BI queries.
Analysis roles: Core of BI authorizations
Analysis roles contain only one object: S_RS_AUTH. You use this to authorize analysis permissions that are not defined in the role itself (see below). In the S_RS_AUTH object, you specify the technical names for the analysis authorizations that are to be assigned to the role.
Caution: SAP already provides predefined analysis authorizations, but these often allow far-reaching data access. For example, users with the field value “0BI_ALL” in the object S_RS_AUTH can access all available data (identical to * characteristic).
Maintaining analysis authorizations in SAP BI
To create or maintain analysis authorizations, use transaction RSECADMIN. You use the “Individual maintenance” function to edit individual analysis authorizations.
Enter a name (observe naming conventions!) and maintain the short and long texts. Add the InfoProvider using the corresponding button. If necessary, you can ask the developer responsible for the correct InfoProvider.
Define special features
Depending on the InfoProvider, you must also add the authorization-relevant special characteristics to the analysis authorization. By default, these are:
- 0TCAACTVT (activity)
- 0TCAIPROV (InfoProvider)
- 0TCAVALID (validity period)
If necessary, other authorization-relevant special characteristics are added. Enter the characteristics as requested and make sure that you do not over-authorize. The characteristics for activity and InfoProvider in particular should never be authorized with.
Good to know: If you have a characteristic that is contained in the InfoCube and is authorization-relevant, you must define it. Even if it is not included in the query, i.e. in the report, or if it is included without selections, an authorization check is performed. In this case, the system checks whether you have authorized aggregated values for the characteristic. In this case, mark the technical characteristic value with “:”. Only in this way will the data from this characteristic be displayed in the relevant report, even if it is not contained in the query itself or only without selection. You do not have to take this into account if you assign a * authorization. Here, in addition to all individual values, the aggregated values for the characteristic are also included.
If you do not know which special features to include, you can use the button with the blue cube (InfoCubes). In the following window, specify the InfoProvider. Now the authorization-relevant special characteristics for this InfoProvider are displayed and can be dragged into the new analysis authorization with one click.
Activate analysis authorizations
Important: If the new analysis authorizations are also to be available in the production system, you must not only save them, but also activate them. To do this, use the corresponding button in the RSECADMIN transaction.
Maintaining analysis authorizations with hierarchies
Now we have created a single analysis authorization. But what about complex reports that should show different data to different user groups? Let’s take a sales report. The data source provides sales figures for various departments or divisions. But the employees of the individual departments should only be allowed to see the sales figures from their area.
Building individual reports or individual analysis permissions for each division or department works, but it is extremely time-consuming. And in large companies, this quickly adds up to an unmanageable amount of roles and permissions.
To get around this, analysis authorizations can also be staggered using hierarchies.
The hierarchies are stored in the respective special characteristics. To find out whether and which hierarchies have been created, call up the analysis authorization in transaction RSECADMIN. In the list of special characteristics, you will find a “Node” column on the far right. If there is a mark here, the characteristic has hierarchies. Open the characteristic and switch to the “Hierarchy authorizations” tab to view details.