BW Security (Authorizations)

The following are some of the relevant SAP BW Security transaction codes.

Transaction Code


Description

RSA1


Transaction RSA1 is the main transaction for administrative functions in SAP BW (Administrator Workbench)

RSD1


This transaction code can be used to mark objects as relevant for authorization (InfoObject Maintainence)

RSSM


This transaction code can be used to create and modify authorization objects in SAP BW

RSZV


This transaction code is used to create or modify the variables for authorization checks. (Variable Maintenance)

RRMX


Business Explorer is the reporting tool in SAP BW and is used for analyzing data.

GLOBAL_TEMPLATES


Templates for modelling and evaluating data


How to Activate Authorizations In BW

The following steps explains how to activate the authorizations in BW.

1) Mark InfoObject as relevant for authorization tcode => RSD1

2) Create report authorization object tcode => RSSM

3) Select InfoCubes tcode => RSSM

4) Manually integrate authorization object in role tcode => PFCG

5) Change / Maintain authorization values => PFCG

6) Assign role to user tcode => PFCG or via Central User Administration

Hierarchical Authorizations in BW

The following steps describe the steps to control authorizations for hierarchies

1) Transfer and activate InfoObject 0TCTAUTHH tcode => RSD1

2) Mark InfoObject 0TCTAUTHH as relevant for authorization tcode => RSD1

3) Mark Leaf InfoObject as relavant for authorization tcode => RSD1

4) Create authorization objects with 0TCTAUTHH and Leaf InfoObject => RSSM

5) Define hierarchical authorizations tcode => RSSM

6) Manual intrgration of authorization object in role tcode => PFCG

7) Maintain authorization values tcode => PFCG

8) Assign role to user tcode => PFCG or via Central User Administration

For extracting structural authorizations from HR (mySAP ERP HCM) and to map it in SAP BW to maintian consistency between the two systems the tables of interest are:

1) T77PR for Structural Authorization profiles

2) T77UA for user assignments

3) T77UU for users (in this table you can select the users for extraction. You can either select all or specific users)
Structural Authorizations in SAP BW

The following steps show the way Structural Authorization is enforced in SAP BW.

The following steps to be carried out in the mySAP ERP HCM system.

1) Call program RHBAUS02 for uploading Table T77UU and enter users.

2) Call program RHBAUUS00 for generating an index for structural authorization profile

3) Activate Data source 0HR_PA_2

The following steps to be carried out in the SAP BW system

1) Replicate Data source 0HR_PA_2

2) Activate ODS InfoProvider 0HR_PA_2

3) Create an InfoPackage to perform an extraction for 0HR_PA_2

4) Load ODS data from mySAP ERP HCM

5) Mark InfoObjects as relevant for authorization (In order to use structural authorizations in SAP BW, all characteristic values like position, employee etc. which are relevant to reporting should be marked as authorization relevant InfoObjects.)

6) Create reporting authorization objects

7) Link authorization objects to InfoCubes

8) Call program RSSB_Generate_Authorizations.

What are BIW and BW?

Not sure this is a useful distinction. Appears to be promoting one vendor's naming convention. ERP and BI were around before SAP made it popular.

Business Information Warehousing (BIW) is a supporting tool that provides interactive, real-time access to data for analysis and manipulation of back office corporate information.

Business Warehousing (BW) is an independent data warehouse solution that provides management reporting to support business decision making and planning.

BIW and BW are simply an efficient manner of transforming industry data for analysis.

BIW and BW have a significant role in Enterprise Resource Planning (ERP) because of the way industries expect data to be flexible and need to run reports exploring the resources and data in an effective manner. In addition, because of the mySAp.cpm invention, the role of the BW has received wide publicity and has therefore increased in demand.

Now SAP BIW or BW takes on a new role as SAP BI which is fully integrated with the netweaver stack. This would lead to better integration with the netweaver stack and make SAP BI an integral part of any SAP Implementation with SAP BI driving the reporting layer.

BIW is the core where == information integration == happens.

What it does is:
- ETL integration check and transformations
- stores structured information in an integrated form.
- provides tools for authorized access, explore and broadcast already accumulated information.
- gives ability to add additional high level business information (planning)
- allows tuning for custom performance.
- provides tools for detailed system and usage monitoring on all levels

What it doesn't do is:
- not suitable to process and play with transactional data
- its not a formated reporting tool for ERP
(This used to be the case until Netweaver 2004s which introduced, among other things formatted reporting and ability to create PDF.

Implementing SSO (R/3 / Enterprise portal)

Implementing Single signon for Enterprise Portal and R/3 Backend

Procedure
Download public-key certificate of Portal Server

Use the Keystore Administration tool to download the verify.der file from the
portal.

Set profile parameters
On all of the component system's application servers:

1. Set the profile parameters login/accept_sso2_ticket = 1 and login/create_sso2_ticket = 0 in every instance profile.

Import public-key certificate of Portal Server to component system's certificate list and
add Portal Server to ACL of component system

Both of these steps can be performed with transaction STRUSTSSO2, which is an extended
version of transaction STRUST. For detailed documentation on transaction STRUST, see the
Web Application Server documentation under Security > Trust Manager.
In the SAP System, start transaction STRUSTSSO2.

A screen with the following layout appears

The PSE status frame on the left displays the PSEs that are defined for the system.

The PSE maintenance section on the top right displays the PSE information for the
PSE selected in the PSE status frame.

Below that, the certificate section displays certificate information for a certificate that
you have selected or imported.

The Single Sign-On ACL section on the bottom right displays the entries in the ACL of
the system.

Note that the layout of the transaction will vary slightly, depending on the
release of the SAP System.

2. In the PSE status frame on the left, choose the system PSE.
3. In the certificate section, choose Import Certificate.
   

The Import Certificate screen appears.

4. Choose the File tab.
5. In the File path field, enter the path of the portal’s verify.der file.
6. Set the file format to DER coded and confirm.
7. In the Trust Manager, choose Add to PSE.
8. Choose Add to ACL, to add the Portal Server to the ACL list.
9. In the dialog box that appears, enter the portal’s system ID and client. By default, the portal’s system ID is the common name (CN) of the Distinguished Name entered during installation of the portal. The default client is 000.

If necessary, you can change these default values by changing the properties login.ticket_issuer and login.ticket_client respectively in user
management properties.

The other values are taken from the certificate.

10. Save your entry.

11. Do not forget to set profile parameters and ITS service parameters as described in Configuring SAP Systems to Accept and Verify SAP Logon Tickets .

Result

The SAP component systems are able to accept SAP logon tickets and verify the Portal
Server's digital signature when they receive a logon ticket from a user.

Importing Portal Certificate into SAP System

Prerequisites
You have downloaded the public-key certificate of the portal server (verify.pse file). Use
the Keystore Administration tool for this.

Procedure

1. In the component system, start transaction STRUST.

The following screen appears.

This screen displays a list of the certificates contained in the PSE of the component system.

2. In the certificate group box, choose Import Certificate.

The Import Certificate screen appears.

3. Choose the File tab.
4. In the File path field, enter the path of the portal’s verify.der file.
5. Set the file format to DER coded and confirm.
6. In the Trust Manager, choose Add to PSE.
7. Save the new certificate list.

The new certificate list is automatically replicated to all application servers in the
system. You do not have to import the portal certificate onto each application
server separately.

BW security Important notes

540720: FAQ Information on S_RS_COMP and S_RS_COMP1
150315: BW-Authorizations for Remote-User in BW and OLTP
315094: Recommendations for authorizations in BW Reporting 2.0B (even though the note was written for 2.0B, it still applies to 3.x)
374297: Checking for referencing characteristics/navigation

BW security

S_RS_COMP
New Authorizations Check for Variables in Query Definition
Object type is ‘VAR’

S_RS_COMP1
Is checked additionally with S_RS_COMP
Checks for authorizations on query components dependent on the owner (creator RSZOWNER)
Authorizations are necessary, e.g. for creating queries

S_RS_FOLD
Suppress InfoAreaview of BExelements
Specify ‚X‘ (true) in the authorization maintenance for suppressing

S_RS_IOBJ
Authorization object for working with InfoObjects
Is checked if authorization is not available via S_RS_ADMWB
Additional checks for update rule authorizations

S_RS_ISET
For displaying / maintaining InfoSets(new object in BW)

S_RFC
Authorization for GUI activities
Add following RFC_NAMEswith RFC_TYPE ‚FUGR‘ and ACTVT ‚16‘
RRXWS: BW Web Interface
RS_PERS_BOD: Personalization of BexOpen Dialog
RSMENU: Roles and Menus

S_GUI
Authorization forGUIactivities. Add the activity 60 (upload)

Create a Reporting Authorization Object

1. In the SAP Easy Access screen of the SAP Business Information
   Warehouse choose Business Explorer >> Authorizations>> Reporting Authorization Objects.
2. Choose Authorization Object >> Create. Enter a technical name and a description for the reporting authorization object. Save your entries. On the right-hand side, you get an overview of all the InfoObjects indicated as authorization-relevant.
   Caution: Only those characteristics that have previously been marked as authorization-relevant in InfoObject maintenance can be assigned to a reporting authorization object as fields.
3. Assign the InfoObject fields to the reporting authorization object:
   Select the characteristics for which an authorization check of the selection conditions should be carried out.
   Select the InfoObject key figure (1KYFNM) if you want to restrict the authorization to a single key figure.
   Select the InfoObject (0TCTAUTHH) if you want to check authorizations for a hierarchy.
4. Save your entries

Steps to Implement InfoObject Security (field-level security)

1. Make the InfoObject authorization-relevant.
   The Authorization Relevant setting for an InfoObject made in the InfoObject definition on the Business Explorer tab. The business needs will drive which InfoObjects should be relevant for security. Keep in mind that the people using SAP BWare running queries to help make strategic decisions on how to better run the business. The decision makers typically need to see more data on SAP BW than they would need to see in SAP R/3.
2. Create a custom reporting authorization object.
   Since there are no reporting authorization objects provided for InfoObjects, you will have to create your own reporting authorization object for any InfoObject you decide to secure. This is done in transaction code RSSM. When creating your reporting authorization object, you select which fields to put in the authorization object from a list of authorization-relevant InfoObjects. Only InfoObjects that have been marked Authorization Relevant are eligible to be put in a reporting authorization object.
3. Add your new authorization object to a role.
   Once you have created an new reporting authorization object and linked it to the appropriate InfoCube(s), users will need access to your reporting authorization object. You will need to manually insert your object into a role.
4. Add a variable to the query.
   The reason the variable is required is sometimes unclear at first. If we want a query to only provide results based on the division, for example, then the query itself needs the ability to filter specific division values. Before we can secure on division, the query must be able to restrict data by division. The only way the query can restrict data dynamically is through a variable.
5. Link the reporting authorization object to an InfoProvider.
   Linking your reporting authorization object to an InfoProvider is a very critical step. In this step, you will impact people currently executing queries for the InfoProvider that is now related to your reporting authorization object. This linkage forces your reporting authorization object to be checked when ANY query tied to the InfoProvider is executed.

BW SECURITY

SAP Business Information Warehouse (SAP BW) as a core component of SAP NetWeaver data warehousing functionality, provides both a business intelligence platform and a suite of business intelligence tools. With the tool set provided, relevant business information can be integrated into SAP BW and transformed and consolidated there. SAP BW enables analysis and interpretation as well as the distribution of this information. Based on this analysis, sound decisions can be made and goal oriented activities can be initiated. With extensive predefined information models provided for the various roles in a company (BI Content), SAP BW also increases the usability of these analyses and enables a quick, cost-effective implementation.

Data warehousing in SAP BW represents the integration, transformation, consolidation, cleanup and storage of data. It also signifies the extraction of data for analysis and interpretation. The data warehousing process includes data modeling, data extraction and the management of the data warehouse management processes.

SAP BW Authorization Specifics
In an SAP BW system there are two different types of authorization objects.

1. Standard authorization objects: This type of authorization objects is provided by SAP and covers all checks for e.g. system administration tasks, data modelling tasks, and for granting access to InfoProviders for reporting. For this type of authorizations the same concept and technique is used as in an SAP R/3 system.
2. Reporting authorization objects: For more granular authorization checks on an InfoProvider’s data you need another type of authorization objects defined by the customer. With these objects you can specify which part of the data within an InfoProvider a user is allowed to see.

Both types of authorization objects use the same authorization framework. Technically they are treated in the same way. However, the design of reporting authorizations is more complex because you need to design the reporting authorization objects first. This is an additional step that needs to be treated with care because the structure of the authorization objects determines the possible use in regards to selections, combinations and granularity. In your project you need expertise in the area of reporting authorizations; knowledge of the basis authorization framework is not sufficient.

User Type in BW

There are different types of users in SAP BW. Most of your users will be the users who execute queries and workbooks. These people could be considered "reporting users" or "end users." To read more about how to secure reporting users click here

There are also users who develop new queries. Some people may refer to them as "power users" or "data analysts." The users who develop queries may also create new workbooks and may be responsible for publishing that information to the right audience.

Then, there are users who create new objects like InfoCubes, InfoAreas, and InfoObjects. They also schedule data loads, create update rules for InfoCubes, monitor performance, and set up source systems. The users who do these tasks are normally referred to as "administration users." read more about how to secure administrator users