BW systems demand large volumes of both current and historical data to efficiently provide important business reporting for decision makers. Many who are responsible for BW global implementations overlook the risks posed by this data with a false notion that BW security is simply a matter of controlling a few areas, such as cost centers, plants, purchasing groups, business areas, and company codes. Perhaps they think that BW security, is similar to R/3 security and uses R/3 security methods such as restricting the transaction codes.

The truth is that BW security implementation is not as easy a task as R/3 security, and it is entirely different. Savvy BW administrators go beyond simply restricting access and focus on securing what really matters — the data itself.

As an OLTP system, R/3 uses an almost endless number of transaction codes. To a large extent, security in R/3 focuses on restricting user activities by limiting specific transaction codes and field values. This is an effective approach because users need access to only those areas relevant to the specific functions they perform, and these users can be easily excluded from many of the system’s transactions and fields. The authorization object S_TCODE primarily drives the user’s security.

However, BW has far fewer transaction codes, and only several such as RSA1 (Administrator Workbench) and RRMX (BEx Analyzer) pose real security concerns. But each one has several components that need to be secured. Security in the BW OLAP environment must cover the actual data in areas such as:

• InfoProviders
• InfoAreas
• Critical InfoObjects
• Key figures
• Hierarchies
• Queries or reports

Because security in BW is imposed on various components, it can affect other parts of BW. For example, if a user is given authorization only for company code A100, then that user can view the query results pertaining to that lone company code and make decisions based solely on that information.

To be able to see and discover the important trends, however, decision makers may need to see data from many or maybe all the company codes. If you need to restrict data at the company code level, or any other level (sales organization, division, business area, etc.) in BW, you can do so by using SAP-provided authorization objects or by creating your own.

I will introduce you to two important BW authorization classes, RS and RSR, and explain how you can deploy them to provide the maximum degree of flexibility while achieving a high level of security. I’ll also show you how you can use these authorization objects along with restricting the transaction codes. At the end, I will present several real-life applications. First, let me provide a little more background on BW security.

Protecting BW

Rather than focusing on transaction codes, for BW security you need concentrate on the data and related components. For example, restricting back-end (RSA1) and front-end (RRMX) access using S_TCODE, as you would with R/3, offers no help in BW because the back-end components/ activities of Administrator Workbench are controlled by SAP-provided authorization objects such as S_RS_ADMWB, S_RS_ICUBE, and S_RS_IOBJ. Similarly, the front-end components/ activities are controlled by authorization objects such as S_RS_COMP, S_RS_COMP1, and S_RS_FOLD. Transaction SU03 provides further documentation on the authorization objects.

SAP provides a number of tools to safeguard data while making it available to those users who must have access to large swaths of information to do their jobs. See the “BW Security Tools” sidebar on page 5 for more details. BW teams also can use R/3 utilities such as the Profile Generator (PFCG) to help them provide flexible high-level security. In addition, two authorization object classes are available for BW to lock down your data while providing enough flexible security to meet various end-user requirements.

Transaction PFCG allows you to create roles and profiles. A role is a collection or authorization objects that provide a profile with appropriate configuration values.

Authorization Object Classes for BW

Authorization object classes are sets of authorization objects meant for controlling specific areas of the SAP landscape (Figure 1). Reporting (RSR) and Business Information Warehouse (RS) make up two authorization object classes available for BW. RS authorization objects protect major administration functions (Table 1). The RSR authorization object class provides field-level reporting security. BW does not ship with any RSR authorization objects. They are created by the BW team as needed.

Figure 1

Revenue and reconciliation account determination select accounts for the FI invoice

Figure 2 shows various objects in the RS and RSR authorization object classes. Note that the RSR authorization objects starting with the letter Z indicate they were created by a BW developer. All RS authorization objects start with S_RS such as S_RS_ADMWB or S_RS_ICUBE. Other SAP R/3 authorization objects start with S_ like S_TCODE, S_DEVELOP, or S_PROGRAM.

Figure 2

Balance sheet impact of reconciliation account determination

If you open or expand any authorization object, you will find its relevant components. For example, the items S_RS_ADMWB from authorization object class RS include InfoPackage, Application Component, InfoArea, Monitor, and other Administrator Workbench components (Figure 3). You can define various values for authorization objects to perform specific tasks such as 01 to create, 02 to change, 03 to display, 16 to execute, or 23 to maintain (Figure 4). The same authorization object can be selected multiple times with different combinations of components and activities.

Figure 3

A typical FI invoice created by SD billing

Figure 4

Revenue and reconciliation account determination work together to select G/L accounts for the FI invoice

Authorization objects can be manipulated to display options for some components while allowing access to other components so they can be executed or maintained. This also allows you to develop profiles for users who are allowed to view and execute certain BW objects such as an InfoPackage or application component, but are not be able to change them.

Figure 5 displays how authorization object S_RS_ADMWB has been tweaked for support team members. The authorization object has been inserted multiple times with different combinations of components and activities so it is tailored to meet the end users’ requirements.

Flexibility

Flexibility is the key to designing and deploying an effective BW security strategy. You must have a thorough understanding of the system’s various components and who is responsible for them as well as what your end users need so you can address all of their demands.

BW developers, for example, usually need full authorization to access all Administrator Workbench components in the development environment. When it comes to testing or working in the production environment, however, they are traditionally restricted to displaying and executing BW objects. Similarly, front-end users can be restricted to display and execute privileges for one category of queries, where power users are granted different authorizations at the query level.

As tempting as it might seem to segregate users and BW team members to the development environment in the name of security, it is often not practical or possible. BW objects such as InfoPackages require developers to create or edit in the testing and the production environment. Likewise, power users must edit or delete ad hoc queries in the testing and production environment. In such cases, individual user profiles are needed based on authorization objects to provide access.

It is easy to see that when developing user profiles, security requirements become complex. You may sometimes need to develop multiple roles to incorporate varied activities for a given user in a single profile. The security strategies could vary from implementation to implementation depending on the business requirements and goals. Flexible configuration of BW’s authorization objects accommodates different types of security strategies.

Your BW Security Plan

Developing a BW security model can follow any number of different tracks. The appropriate model is best determined by the kind of organization and its operational activities. Authorization objects can help support almost any security implementation.

A security plan should be based on any of the following criteria, either alone or in combination:

• Groups working in BW
• Functional areas (SD, MM, FI, etc.)
• Geographical regions
• InfoProviders
• Types of data

For plans based on user types such as super users, administrators, developers, and end users, profiles are set up by customizing authorization objects. In the production environment, for example, you can allow super users to create, edit, and delete specific objects without the ability to edit or change others. These profiles should be created using authorization objects like S_RS_COMP and S_RS_COMP1 with appropriate values.

Security can also be based on functional areas such as FI, SD, and MM so that functional staff from one area cannot access data from another area. Here, strict naming conventions must be practiced when creating InfoAreas and the application component areas in Administrator Workbench (Figure 6). Areas that need to be secured must be intact under one InfoArea with a standard name like ZMM_INFOAREA. Similarly, you can secure relevant InfoSources by using application component names. InfoSources are created in application component areas, and each application component area represents a functional area (Figure 7). More than one InfoArea or application component area can represent the same funtional area.

Customizing Templates

SAP provides templates that are a big timesaver when developing profiles. While it is essential to understand authorization objects and to use them intelligently when creating roles for your end users, thanks to the templates you needn’t memorize each one.

To access the templates, create a role using transaction PFCG and click on the Expert Mode for Profile Generation (Figure 8) from the Authorizations tab. You will be presented with a list of templates to choose from that are easily adopted and customized to suit your specific requirements (Figure 9).

If you are developing a profile for a reporting user, for example, you select S_RS_RREPU, or for an administrator profile in a development system, select S_RS_RDEAD. After selecting the appropriate template, you can customize it by removing or adding the authorization objects of the authorization object classes. This allows you to prepare a profile tailored to the desired security requirement.

Achieve Regional Security

Companies that use the same BW environment worldwide need to implement regional security. This approach allows you to restrict North American users from accessing data for Asia Pacific users and vice versa.

To achieve geographical security, you first need to enlist a functional consultant and identify the InfoObjects that determine the regions. A company code, for example, decides the region in finance area.

Make an InfoObject’s authorization relevant by deploying transaction RSD1 and checking the AuthorizationRelevant box (Figure 10). Create a new RSR reporting authorization object ZCOMPCODE via transaction RSSM (Figure 11) to restrict regional access. Use RSSM to assign InfoObject 0COMP_CODE to the new authorization object to determine the regions, and check the InfoProviders containing the 0COMP_CODE.

Figure 10

Define special G/L indicator T for account type D customers

Figure 11

Define properties for special G/L indicator T (relevant to credit check box is not checked)

Now, insert ZCOMPCODE manually into the profile via PFCG to assign this new authorization object to the finance group profile with the appropriate values for the regions. For example, if A001 represents the region Europe, then users with this profile can access the data relevant to Europe only.

Figure 12

Define the alternate reconciliation account for the special G/L indicator

In the same way they support regional security, reporting authorization objects allow you to offer security protection at various organizational levels such as cost centers, controlling areas, and sales and purchase organizations. The appropriate InfoObject determines the organizational level in the same manner that InfoObjects determine geographic regions.

BW Security Tools

In addition to RS and RSR authorization objects, various tools are provided by SAP for tailoring, maintaining, and testing your BW security implementation. The list of tools includes the Profile Generator (PFCG), transaction RSSM for maintaining authorizations, SU03 for manually editing authorizations, SU01 for performing user profile maintenance, SU53 to display check values, and ST01 to perform a system trace.

You can use authorization object S_TCODE from the AAAB class of cross application authorization objects to provide additional BW security. With authorization object S_TCODE, you can authorize a list of exclusive transactions a user can access (Figure 1). Use the wild card character (*) for the S-TCODE value to authorize all the transactions.

Figure 1

Revenue and reconciliation account determination select accounts for the FI invoice

After deciding on the appropriate template, you can customize the authorization objects by assigning authorization object components a value and choosing the relevant activity. For example, assigning the value RS* to roles in authorization object S_TCODE grants access only to the transaction codes starting with RS and denies access to all other transactions. Use SU53 to check authorization object values and display details (Figure 2).

Figure 2

Balance sheet impact of reconciliation account determination

Use SU03 to display details for authorization object classes along with their authorization objects and detailed documentation. Select any authorization object class and double-click to see a list of all the authorization objects contained in that class. Select any authorization object to study its properties.

 

Raju Veludandi

Raju Veludandi is BW Practice Director at Compugra Systems Inc. with experience in BW design and development. He has set up security models for many BW and SEM implementations, and is certified by SAP in BW 3.0. With over six years experience on different SAP implementations, Raju has worked with major clients such as Eli Lilly, Mass Mutual, Nike, Synopsis, and Hewlett- Packard. He is currently working with HP.

You may contact the author at rveludandi@compugra.com.

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