1

BW365 BI User Management and

Authorizations - V2006Q2



Table of Contents

Unit #1: BI Overview .............................................................................................................. 2
Unit #2: Security Components in BI ..................................................................................... 3
Unit #3: Important Aspects of BI Authorizations ............................................................... 9
Unit #4: Securing Data Access for Reporting Users ........................................................ 11
Unit #5: Saving BEx Objects to BI Roles ........................................................................... 17
Unit #6: Securing Data Access for Administrator Users .................................................. 18
Unit #7: Maintaining Authorizations ................................................................................... 21
Unit #8: Authorizations for Business Planning & Simulation .......................................... 26
Unit #9: Appendices ............................................................................................................. 29




























2

Unit #1: BI Overview

A PSA object is the initial storage area of data, where requested data is saved, unchanged from the
source system, according to the structure defined in the DataSource. A PSA can be created for each
DataSource and source system.

An InfoObject has three classes ofmetadata: technical (data type, length), business definition (such
as key performance indicators) and user metadata which carries information about authorizations.

Query results may also be distributed to folders in the Knowledge Management environment in the
Enterprise Portal or to Collaboration Rooms in the Enterprise Portal.












































3

Unit #2: Security Components in BI

MySAP ERP security is focused on:
Transaction codes
Specific field values
Which activities a user can perform

Instead BI is focused on what data a user can access. The security function in BI focuses on:
InfoAreas
InfoProvider (InfoCube, DataStore Objects)
Queries



Before implementing security, you need to ensure the level of security like company code level, or
any other level (sales organization, division, business area, etc) is in line with the goals of the BI
implementation.

System Communication Security:
To set up system security, you must set up security for all SAP source systems sending data to BI, in
addition to setting up security on BI.

In BI, you should create a system (not a dialog) user called BWREMOTE. BWREMOTE should have the
authorization profile S_BI-WHM_RFC. S_BI-WHM- RFC is a profile, not a role. This profile will give
user BWREMOTE the access needed to extract from an OLTP system & to get the data into
InfoCubes.

You must set up a system user called BWALEREMOTE on each SAP system sending data to BI. This
user should have the authorization profile S_BI-WX_RFC. This profile will give user BWALEREMOTE
the access needed to connect and send data to the B1 system.

It is permissible to use a different name for the users BWREMOTE and BWALEREMOTE but what
matters is user profile.
4


RFC destinations define where the other systems reside and how to log on to the other systems. E.g.
RFC (Remote Function Call) destinations tell BI where the source systems are physically located.





A system user ID cannot log on to a system via a normal GUI screen. The user ID is only for
background communication. These user IDs are used exclusively for data extraction processes.

For other system-to-system communication processes in BI other than data extraction (like RRI from
BI Query to a transaction or report in ECC, monitoring of the IDocs generated during data extracted
from the source systems), there is another RFC destination defined: the
<RFC_DESTINATION>_DIALOG destination.

When setting up the RFC destination <RFC_DESTINATION>_DIALOG, you have some choices
regarding the user ID specified:
1. Force the user to always log on to mySAP ERP after selecting OLTP by leaving the User field
blank in <RFC_DESTINATION>_DIALOG.
2. Create a generic user in mySAP ERP with access to monitor IDOCS; use this user in the
<RFC_DESTINATION>_DIALOG destination.
3. In the RFC destination, select Current User. This will use the current BI user's user ID to log
them on to mySAP ERP.

5

If you use Current User, the system tries to use the same user ID in BI and mySAP ERP. If the user
ID does not exist in mySAP ERP, then the user will be prompted for a user ID and password.



Authorizations in BI:
There are two major types of authorizations in BI
1. Administrative users
a. S_RS_ADMWB Administrator Tasks such as setting up InfoCubes, managing the
loading of data from the source systems, managing the DTP and handling all the
transformations are secured with this authorization object.
2. Reporting users
a. S_RS_COMP This authorization object is very important for reporting. This gives
you the option to secure by query name, InfoArea, or InfoCube. E.g. user can create
queries only for their application area
i. with a naming convention for each area. i.e. in accounts receivables all
queries must start with AR.
ii. You have linked the application area to a specific InfoArea and InfoCube. The
user can create any query with any name as long as they only create queries
for "their" InfoCube.
b. S_RS_COMP1 Authorization for queries from specific owners. It can be used to
limit, by the query owner, which queries a user can see. E.g. you can only see
queries created by the power user for your area.
c. S_RS_FOLD Display authorization for folder. E.g. the reporting user should only be
able to see their Favourites folder and their assigned roles.
3. Both users
a. S_RS_HIER It primarily protects who can create hierarchies and who can execute
queries that use hierarchies.


Analysis Authorizations:
The options include
a. InfoCube Level: Restrict at the InfoCube level.
b. Characteristic Level: Restrict access to all values for a particular characteristic.
c. Characteristic Value Level: Restrict access to certain values of a particular characteristic.
d. Key Figure Level: Restrict access to certain key figures.
e. Hierarchy Node: Restrict access to certain nodes of a hierarchy.

6

You either get the compete result or nothing at all.
Exceptions to this rule are:
a. Display hierarchies are automatically filtered by the authorization (the system doesn't give
you a blank result just because you should only see a part of the hierarchy. You will see only
the nodes you are authorized to see.
b. Key figure values are not displayed if the key figure is not authorized. You don't get a blank
screen if you don't have access to one or two key figures you will still see the key figures you
are authorized to see.

The characteristics must be flagged as Authorization Relevant before they can be secured.

Tcode RSECADMIN is used for central maintenance of Analysis Authorizations. As a pre-requisite, you
have authorization for authorization object S_RSEC.

1. A choose the characteristics which you want to secure. You can choose multiple
characteristics.




2. Choose the values for the characteristics you have defined in the previous step. Also select
options such as EQ, BT or CP (Contains Pattern).
7



There are 3 special Business Content characteristics which SAP recommends that you include in at
least one of your authorizations:
1. 0TCAACTVT, Activity: display (03), etc.
2. 0TCAIPROV, InfoProvider: grants authorization to particular InfoProviders.
3. 0TCAVALID, Validity: grants authorization to specific time periods.
They must not be included in Queries.



For key figure authorizations, you can include 0TCAKYFNM as characteristic into the authorization.
Note: hierarchy authorizations are not allowed on this characteristic. Once you define 0TCAKYFNM
authorization-relevant, key figures are checked for every InfoProvider.

Special authorizations
1. * (asterisk): denotes a set of arbitrary characters
2. + (pius): denotes exactly one character (e.g. 01.++.2005 until 10.++.2005: allows access
only the first 10 days of each month in 2005 - only available for time validity (OTCAVALlDjj
3. : (colon): allows only aggregated access to data (e.g. allows information on all sales areas
only on aggregated level- not on particular countries)

An authorization for all values of all authorization-relevant characteristics is created automatically in
the system. It has the name 0BI_ALL. It can be viewed, but not changed. Every user that receives
this authorization can access all the data at any time. Each time an InfoObject is activated and the
property authorization relevant is changed for the characteristic or a navigation attribute, 0BI_ALL is
8

automatically adjusted. A user that has a profile with the authorization object S_RS_AUTH and has
entered 0BI_ALL has complete access to all data.

If you want to grant authorizations on navigational attributes, mark them authorization relevant in the
attribute tab strip. You don't need to make the main characteristic as authorization relevant in order
to make the navigational attribute authorization relevant.



The navigational attribute can be assigned individually. The referencing characteristic
(0D_SALE_ORG) need not be authorization relevant.























9

Unit #3: Important Aspects of BI Authorizations

Standard Authorizations are the ones based on structures delivered by SAP. They allow users to
perform administration tasks or to create, change or delete meta data objects like InfoObjects or
InfoCubes. Granting the authorization to the users is the customer's only responsibility.

Analysis Authorizations define semantic data slices a user is allowed to see in reporting. The structure
and values are completely customer-defined. It is the customer's responsibility to define the
components (InfoObjects) that are relevant for the authorization checks.






Query Selections
Belong to query
Are defined by fixed and dynamic filters
Are checked at runtime for matching analysis authorizations
Is a rectangular subset of the multi-dimensional space
Analysis Authorizations
Are defined independent of queries
Union of authorizations may be a complex structure (not rectangular)

10



If a user had these authorizations assigned, the rectangular superset of the authorizations in a query
selection would result in an authorization check failure. The subset selection would not fail the
authorization check but it fails to display all authorized values.

If you use variables of type authorization (filled automatically with authorized values) for both
characteristics in the example, the query filters the query according to the union of all values, thus
authorization check fails.






























11

Unit #4: Securing Data Access for Reporting Users

Minimum Authorization Requirements for a Reporting User
Analysis authorizations for an InfoProvider
S_RS_COMP (Activities 03, 16)
S_RS_COMP1 (Query owner)
S_RFC (BEx Analyzer or BEx Browser only)
S_TCODE (RRMX for BEx Analyzer)

Steps to Implement InfoObject Security (Field-Level Security)
Define the InfoObject as authorization relevant.
Create (or adjust) analysis authorizations for an InfoObject. This is done in tcode
RSECADMIN. Only InfoObjects that have been marked Authorization Relevant are eligible to
be put in an analysis authorization.
Assign authorizations to users. You can assign authorizations in roles using S_RS_AUTH or
directly in transaction RSECADMIN or RSU01.
Add a variable to the queries. In this case, the user-input variable only has the input help
options which the user is eligible for.

When a user brings up the BEx Analyzer or uses the Query Designer for Web-based reporting, there
are four categories from which they may choose existing queries: History, Favourites, Roles, and
InfoAreas. S_RS_FOLD: Disable the InfoAreas button in the BEx Analyzer Open Queries dialog box.
Display authorization for folder. E.g. the reporting user should only be able to see their Favourites
folder and their assigned roles. S_RS_COMP1 is used to restrict access based on Query Owner. But
other queries for which the Created by field of the query is blank, may be available. You can assign
authorizations to transport requests in transaction RSECADMIN.

Two Purposes for Colon (:) Authorization Value
1. Enable Execution of Queries that do not contain authorization relevant InfoObject that are
checked in the InfoCube
2. Enable summary data to be reported for characteristics level where user does not have
authorization to access detailed data

Once an InfoObject is authorization relevant, ALL queries on all InfoProviders containing that
InfoObject will be checked for authorization; even if the InfoObject is not contained in such a query.
Every query that does not use the secured InfoObject(s) will fail if the user does not have a ":" value
or full authorization in their authorization.

It is feasible that a sales manager is allowed to view the respective total sales figures for all sales
organization, but is only authorized to break down their specific sales organization (000 I) according
to the individual sales employees.



Using a Pound Sign (#) as an Authorization Value
12

The # character is interpreted as authorization for the display of the value Not assigned (posted with
INITIAL).

When data is loaded into SAP BW, some fields may be marked as "no value assigned" (posted with
INITIAL). If you have secured an InfoObject that has data that is unassigned in the InfoCube, you
may choose to give the user a pound sign (#) in order to avoid an authorization error at runtime.

There are two different ways variables are used for authorization processing.
1. Customer Exit Variable It can be used with the special value $ (as escape sequence) as
prefix before the variable name. This enables dynamic granting of authorizations (authorized
values are retrieved at runtime).
2. Authorization variable It reads the authorization data, then a dialog box does not appear
and the query results include all divisions for which the user is authorized. Additionally, the
Ready for Input checkbox should NOT be selected if the query user should automatically
receive data for all values for which they are authorized. If the Input Ready checkbox is
selected, the user gets a dialog box for entering the desired characteristic values. With F4
help or the down arrow, however, only the values for which the user is authorized are called.



Hierarchy security can be setup multiple ways as enabling the user to see the entire hierarchy, only
the nodes, or the subtree below the nodes.

Steps to Implement Security on the Hierarchy Level
1. Make the InfoObject on which the hierarchy is based authorization-relevant.
2. To create hierarchy node authorizations, in the detail maintenance choose the tab Hierarchy
Authorization.



3. Create a hierarchy authorization and select the hierarchy and node.

4. Select the Type of authorization:
a. 0 for the node
b. 1 for a sub-tree below the node
13

c. 2 for a sub-tree below the node up to and including the levels for a sub-tree below
the node.
d. 3 for the entire hierarchy
e. 4 for a sub-tree below the node up to and including levels (relative). (You have to
specify a level that is defined relative to the node. It makes sense to specify a
relative distance if an employee may only expand the hierarchy to a certain depth
below his initial node, but this node is moved to another level when the hierarchy is
restructured.)
5. Optionally you can use the following fields:
a. Top of hierarchy This option allows you to select the top of the hierarchy instead of
a node in the hierarchy.
If, on the other hand, the hierarchy is used in the query without a filter set for this
node, the user is not able to execute the query. This is because the node that is
displayed at the highest level in the hierarchy is not actually the top of the hierarchy.
For example, there is the 'All Other Leaves' node. This is an internal node, but a node
in the hierarchy nevertheless, and it is this node that is at the top of the hierarchy, a
level higher than the highest node that appears in the hierarchy display. If the
hierarchy is used in the query, and the top-level node has not been specified
explicitly, the system checks the authorization against the highest node in the
hierarchy, meaning the internal node that is not displayed. This option, therefore,
allows you to determine the top-level node of the hierarchy yourself, so that you can
ensure that users are assigned the appropriate authorizations.
b. Hierarchy level Within the framework of the authorization check, you can use this
value to specify to which level the user can expand the hierarchy.
c. Area of Validity
i. 0: Name, Version, and key Date identical
ii. 1: Name and version identical
iii. 2: Name identical
iv. 3: All hierarchies

There are two primary transaction codes that can be used to trace authorizations: ST01 and
RSECADMIN.
1. Tcode ST01 is a system trace that is used for SAP-provided objects.
2. Tcode RSECADMIN is specific to BI and only traces the custom reporting authorization objects
you create to control access to InfoObject values.
a. Choose the tab Analysis.
b. There are two possibilities to trace:
i. Choose the button Error Logs, add the user to the list and ask the user to run
the query. This can be used permanently if legal auditing is required.
ii. Choose the button Execution as, type the user name, check With Log and
execute the query yourself.
c. To look at the trace results, use the Display button in Error Logs after selecting the
right log with the value help.



14

Using Tcode RSECADMIN

The authorization checks are performed only for analysis authorizations with exception: S_RS_COMP
which is also checked for the restricted user and S_TCODE which is checked for the transaction that
is called (e.g. RSRT). The executing user needs corresponding permissions on the authorization
object S_RSEC to execute the transaction as other user. If this authorization is missing the password
of the restricted user is required to authenticate the execution.





1. Query starts
2. List of authorized attribute is requested
3. Variable processing and Value Help (F4): Hierarchy authorizations and value authorizations
are requested. Each request results in an individual block.
4. Before checking for the details of the displayed data, the system checks for the authorization
to the InfoProvider with a certain activity. If access is granted, the more detailed checks
follow. Otherwise the query results in a message "No authorization to InfoProvider" (EYE 001)
5. Then the list of authorization relevant characteristics of the InfoProvider is determined
6. As a last step the access to selected data in a certain navigational step is checked always if
necessary. If this check fails, there are some combinations for selected data are not
authorized. A message "No sufficient authorizations" (EYE 007).
7. In planning the InfoProvider specific checks are repeated for different activities

The protocol will be persisted on the database in an XML-based format and can be displayed in a
readable form as HTML-Page.

Detail of the protocol view
1. Protocol Header At the beginning of each protocol there is a header that contains time and
date of the executed authorization check, if available query name and InfoProvider name, the
name of the user who has executed the query and possibly the name of the restricted user
which may be different if the query was executed by a power user with analysis
authorizations for another user. A time stamp (with the execution time on the local server
15

and the time of the server of execution) and the calling transaction is listed. All the following
blocks are separated by header lines with an underlying colour.
2. InfoProvider Check A check for a sufficient combination on the mandatory InfoObjects
0TCAIPROV (InfoProvider), 0TCAACTVT (Activity) and 0TCAVALID (Validity of the
authorization). The message number and class is EYE 001. At this point no (semantical)
characteristic values or key figures have been checked.
3. Attributes There is always a check for the attributes which are authorized for an InfoObject.
For display attributes that are authorization relevant, the full authorization is required (*).
Otherwise the attribute will be hidden from the system (query design and execution).
4. Value Authorizations Here the list for authorized values on a characteristic is presented.
Value authorizations are always combined from all valid authorizations for the current
InfoProvider. This means that all values from all authorizations for this InfoProvider are put
together into the list of authorized values. It is possible to check whether this expected result.
In some cases the authorized values are displayed as integer numbers, so-called surrogate
Ids or in short SIDs.
5. Hierarchy (Node) Authorizations Here the list of authorized nodes is given together with
some more technical information on the authorizations such as Authorization Type, Level,
Validity Scope, together with information on the selected hierarchy itself.
6. Relevant Characteristics The list of characteristics that are actually relevant for the
authorization checks is determined. It is the list of all characteristics that are marked as
authorization relevant in the InfoObject maintenance, including Navigational Attributes
reduced by those ones for which the user has full authorizations (*).
7. Detailed Checks The selection is separated into various sub-selections, which carry a
number (SUBNR). The selected set of data must be a subset of the authorized data.
Authorizations do not automatically work as query filters.
a. Aggregation Check and Aggregation Authorization As a first step, in for every sub-
selection it is checked whether a check for aggregation authorization is necessary
which depends on the navigational state. All characteristics that are authorization
relevant but not in drilldown or even not in the query (but in the InfoProvider) must
be authorized with aggregation authorization (:). If aggregation checks are
performed you need to have aggregation or full authorization for the characteristic.
This is a frequent cause of authorization failure.
b. Set Comparison Next step is the comparison of all sub-selections (SUBNR) with all
authorizations that are assigned and valid today and valid for the InfoProvider.
i. Compare selection set with all authorizations and find out, whether the
selected set is a subset of (or equal to) the authorization set.
Yes: Selection is authorized
No: calculate the authorized part (intersection of selection with
authorization) and the non-authorized rest set. Put the rest set to the
list of selection parts that still must be checked. (it might be that the
rest set is authorized by another authorization)
ii. If any selection or rest set is left, go to step 1 again.
8. Buffer Filling, Pre-Optimizations All information on authorizations are usually required
several times, for example during navigational steps or even for several value helps on
authorization relevant InfoObjects. Since the preparing steps that must or may be done
before actual authorization processing take a certain amount of time, all necessary
information is buffered at the first call. The most important steps of this buffering are
extension and merging of authorizations which means summarizing authorization that can
enhance each other.
a. Extension adds authorizations for characteristics that are not included in an
authorization from other authorizations.
b. Merging summarizes authorizations that differ in one dimension (one characteristics).


Using Tcode ST01
Transaction code ST01 executes a trace tool that exists on all ABAP based systems. this tool serves as
trace for all SAP-provided authorizations objects. You simply turn on the trace (for a specific user),
16

and when the trace is completed you can see which authorization objects were checked and the
results of the check. Analysis authorizations will not appear in the ST01 trace.

If you want to use the ST01 trace tool, you only have to activate the trace and filter for a specific
user. To do this use, Edit Filter General in transaction code ST01. Since authorization objects
S_RS_COMP and S_RS_COMP1 are checked when building the list of queries displayed in the BEx
Analyzer tool, all InfoAreas and InfoCubes you do not have access to will appear in the lighter shade.



RSSM is the transaction used for the old authorization concept in SAP BW 3.5 and below. The main
transaction for analysis authorizations is RSECADMIN.

Inserting variables in queries makes the query much more flexible. You do not have to create multiple
versions of the same query to handle different selection criteria. Since the variable can access the
authorized values for a user, it is a very efficient way to implement InfoObject-level security. Thus,
creating variables for queries that use the secured InfoObject is a requirement for efficient
implementation of InfoObject-level security.

Using $ as an authorization value implies that the customer-exit variable fills the authorizations
dynamically.






















17

Unit #5: Saving BEx Objects to BI Roles

You can allow only power users to save workbooks to maintain the roles and ensure that the
workbooks remain manageable. This also prevents users from changing workbooks saved by other
users.

In order to save workbooks to roles, a user needs
1. S_BDS_DS The workbooks are stored in a database on the BW server. Saving workbooks is
primarily protected by S_BDS_DS.
Following authorizations protect roles
2. S_USER_AGR: Authorizations: Role check This has following two fields.
a. Activity
i. 01 Add or Create
ii. 02 Change
iii. 06 Delete
iv. 22
b. Role Name the specific roles you have created for saving workbooks
When a workbook is saved in a role, the area Menu for a role is changed. Thus the object
S_USER_AGR is a required object.
3. S_USER_TCD: Transactions in roles Value of Tcode RRMX

Workbbooks can be added to a role from Role Maintenance, PFCG: from the Menu Tab, choose Add
Report, BW Report. Enter the Technical Name of the Workbook. The BI Workbook directory tables are
RSRWBlNDEX and RSRWBINDEXT.

Transporting a role from DEV to PRD, overwrites the role in PRD. Thus, if any workbooks created &
attached to this role in PRD, will not be attached to that role anymore after transport. For the roles
with workbooks, it probably will be best for the security administrator to create specific roles for
workbooks that only contain workbooks with NO authorizations. Any changes made to the role will be
from workbooks being created and saved to this role in a production environment. This role should be
created in DEV and transported to PRO, but it should be empty and no other subsequent transports
should occur for this role.

Use report RSWB_REORG_ROLES to identify what workbooks are not attached to a role. Also, you
can use this report to delete unused workbooks.





















18

Unit #6: Securing Data Access for Administrator Users

Administrators must have access to Data Warehousing Workbench objects, such as InfoProviders,
Data Transfer processes, Process Chains, Reporting Agent objects, Open Hub destinations, and
DataSources.

1. Authorization object S_RS_ADMWB protects these objects. There are only 2 fields attached to
this authorization object:
a. Data Warehousing object
i. SourceSys (Source system)
ii. InfoObject (InfoObject)
iii. Monitor (Monitor)
iv. ApplComp (Application components)
v. InfoArea (InfoArea)
vi. Workbench (Data Warehousing Workbench)
vii. Settings (Settings)
viii. MetaData (Metadata)
ix. InfoPackag (InfoPackage and InfoPackage Group)
x. RA_Setting (Reporting Agent setting)
xi. RA_Package (Reporting Agent package)
xii. DOC_META (Documents for metadata) Authorizaton to display or to edit a
metadata object, also authorizes the user to display or edit the documents
for these metadata objects. Valid activities are: 03 (display), 23 (maintain)
xiii. DOC_MAST (Documents for master data) Authorization to display or to edit
in specific master data, also authorized the user to display or edit the
documents for these characteristic values. Valid activities are: 03 (display),
23 (maintain)
xiv. DOC HIER (Documents for hierarchies)
xv. DOC_TRAN (Documents for transaction data)
xvi. DOC ADMIN (Administration of document store)
xvii. CONT_ADMIN (Administration of Content systems)
xviii. CONT_ACT (Installation of Business Content)
xix. BR SETTING (Broadcast settings other than your own settings, which have
one of the following distribution types: Send e-mail, send to the portal, send
to the printer.)
xx. USE DND (Drag and Drop to InfoAreas and application components)
xxi. CNG_RUN (Attribute change run)
xxii. REMOD RULE (Modeling Rule "Modeling Rule" for the remodeling tool)
xxiii. IMG BI (BI-relevant activities in IMG)
xxiv. OLAP CACHE (OLAP cache objects)
xxv. HPA_ZA (BIA Monitor checks and activities)
b. Activity

2. S_RS_MPRO Authorizations for working with MultiProviders and their subobjects

3. S_RS_ICUBE Authorizations for working with InfoCubes and their subobjects like
a. Definition Definition
b. UpdateRule - Update rules
c. Data Data
d. Aggregate Aggregate
e. ExporllSrc - Export DataSource
f. Chavlrel - Characteristic relations (planning relevant)
g. Dataslice - Data slices (planning relevant)

4. S_RS_ODSO Authorizations for working with DataStore objects and their subobjects.
5. S_RS_ISET Authorizations for working with InfoSets
6. S_RS_HIER Authorizations for working with hierarchies
19

7. S_RS_IOMAD Authorizations for processing master data in the Data Warehousing
Workbench
8. S_RS_DS Authorizations for working with the DataSource(Release> BW 3.x) or its
subobjects. It has 3 fields
- Name of DataSource that a user is allowed to edit.
- Source System for which a user is allowed to edit.
- Subobject for DataSources like
Definition
Data
InfoPack
9. S_RS_DTP Authorizations for working with the data transfer process and its subobjects.
This authorization has a higher priority than the authorizations for the underlying objects.
Users that have a DTP authorization for a source/target combination do not need read
authorization for the source object or write authorization for the target object to execute the
DTP.
10. S_RS_ISNEW Authorizations for working with InfoSources (Release> BW 3.x)
11. S_RS_ISOUR Authorizations for working with InfoSources with flexible updating and their
subobjects
12. S_RS_ISRCM Authorizations for working with InfoSources with direct updating and their
subobjects
13. S_RS_TR Authorizations for working with transformation rules and their subobjects
14. S_RS_IOBJ Authorizations for working with individual InfoObjects and their subobjects
15. S_RS_PC Authorizations for working with process chains. In addition, S_RS_ADMWB is
required to maintain processes attached in PCs.
16. S_RS_OHDEST Authorizations for working with open hub destinations

17. S_RO_BCTRA - Authorization to remotely activate the associated source system DataSources
during the process of activating Business Content in BI. It is valid for all DataSources of a
source system. When the objects are collected, the system checks the authorizations
remotely. The system issues a warning if you do not have authorization to activate the
DataSources. The activation is done using the <logical system name>_DIALOG RFC
destination. There will be a prompt for UserID and Password. During activation, the
DataSources in the source system are transferred to the active version and replicated in the
BI system.
A prerequisite for this feature is that the source system must have BI Service API SAP
NetWeaver 2004s (PI_Basis2005.1); otherwise remote activation is not supported.

18. S_RS_BTMP - Authorizations for working with BEx Web templates. It has 3 fields : Name,
Owner, & Activity.
S_RS_BITM - Authorizations for working with BEx Web items. It has 3 fields : Name, Owner,
& Activity.
S_RS_BEXTX - Authorizations for the maintenance of BEx texts. Text is a common textpool
with language dependent texts maintained via BEx.

19. RSDMEMBW Authorization for uploading data mining results into the BI system
RSDMEMODEL Authorization for working with analytical models
Each analysis process is only valid for the application for which it was created. The
authorizations are also assigned specific to an application and are protected with
authorization object RSANPR.

20. S_RS_BCS - Authorization for registering broadcast settings for execution. Special
authorizations are required for Information Broadcasting.
Administrators need authorization object S_RS_ADMWB with the field RSADMWBOBJ =
BR_SETTING.
Users that schedule distribution using Information Broadcasting, require the authorization
object S_RS_BCS.

20

The authorization object S_BTCH_NAM is required for regular scheduling in background jobs.

Role to Secure Master Data
To grant authorizations for characteristics, activate authorization assignment by setting Authorization
Check indicator in the Master Data/Texts tab page. Two authorization objects exist for this:
S_RS_IOMAD a blanket authorization check takes place for a characteristic.
S_TABU_LIN an authorization check takes place by characteristic value.
An additional authorization object is needed:
S_TCODE Transaction code, RSRMD, for master data maintenance.

From the Enterprise Portal, user mapping is required for two methods of Single Sign-On to backend
systems:
1. SSO using user ID and password (UIDPW) It is necessary to map the portal user ID and
password to the user ID and password in the backend system.
2. SAP logon tickets for Single Sign-On to SAP Systems (SAPLOGONTICKET) In this case,
users have the same user IDs both in the portal and in ABAP-based SAP systems, there is no
need for user mapping. A user's portal user ID and the SAP user ID are stored in the user's
SAP logon ticket. When the user tries to access a component system, the system extracts the
user ID from the logon ticket (passwords are not sent across networks).






































21

Unit #7: Maintaining Authorizations

Options for Authorization Maintenance
Role Maintenance
o Standard
o Correct customizing of roles is important
Reusable basic roles separate from more individual roles
Menu functions of roles separate from authorizations as needed
Avoid overlaps

Analysis Authorization Maintenance
All activities for managing the components of analysis authorizations are maintained in the
Management of Analysis Authorizations transaction, RSECADMIN. The authorization object
S_RSEC protects the analysis authorization maintenance.
Analysis Authorizations can be assigned to Roles using the authorization object S_RS_AUTH.

Customer exit variables for variable authorization assignment
Function of a Variable
o Normal filtering of queries
o Hierarchy: determine authorized values
The authorization assignment via customer exit variables has NOTHING to do with the
concept of variables of processing type "authorization".
The advantage of this method is that you can give all users the same authorization by placing
the variable name with a $ sign in front of it instead of a value in the characteristic value (or
the hierarchy node).

Use enhancement RSR00001 (tcode CMOD) for the necessary ASAP coding.
The variable can also of course be used in the query, but this is not absolutely necessary. You
can also filter using another variable or with fixed value restrictions in the query.

Generate automatic authorizations

Authorization data is loaded into Data Store Objects and then authorizations are generated
with the information from the Data Store Objects. A prerequisite for this is that authorization
data does exist in some form (in a source system) that can be brought into BI with the usual
data loading process.

There are five Data Store Objects delivered with Business Content that serve as templates:
o 0TCA_DS01 Authorization Data - Values
o 0TCA_DS02 Authorization Data - Hierarchies
o 0TCA_DS03 Descriptive Text Authorizations
o 0TCA_DS04 Assignment User Authorizations
o 0TCA_DS05 Generate Users for Authorizations

22

For every authorization scenario - typically per authorization object that is to be generated for
authorizations - the required DataStore objects should be copied into their own namespace
(for example, HR_DS01, HR_DS02, ...). In this way, the data for different scenarios is kept
separate.

Leave the key field User empty in Data Store Object 0TCA_DS01 and 0TCA_DS02 and
generate the authorizations. You then get a profile that can be assigned to any number of
users. The profile gets its text from the Data Store Object 0TCA_DS03. You maintain the
users in Data Store Object 0TCA_DS04.

Structure of DSO 0TCA_DS01
InfoObject Description Source or Value
0TCTUSERNAME User for which the Authorizations is
generated
From Source Data
0TCTAUTH Technical Name of Authorization Initial or Name you assigned
0TCTADTO Validity of the Authorization 12.31.9999 or from source
data
0TCTIOBJNM Name of Authorization-relevant Object Assignment of Source Field
0TCTSIGN Sign I Inclusive
0TCTOPTION Selection Operator EQ Single Value
BT Interval
0TCTLOW Value or Lower Interval Value From Source Data
0TCTHIGH Upper Interval Value From Source Data
0TCTOBJVERS InfoObject Version A Active
0TCTSYSID BW System ID Initial or System ID
0TCTADFROM Begin of Validity 19000101 or Source


Structure of DSO 0TCA_DS02
InfoObject Description Source or Value
0TCTUSERNAME User for which the Authorizations is
generated
From Source Data
0TCTAUTH Technical Name of Authorization Initial or Name you assigned
0TCTADTO Validity of the Authorization 12.31.9999 or from source
data
0TCTIOBJNM Name of Authorization-relevant Object Assignment of Source Field
0TCTHIENM Name of Hierarchy Constant or from Source
Data
0TCTHIEDATE Hierarchy Key Date Initial or Key Date
0TCTNIOBJNM InfoObject of the Hierarchy Node 0HIER_NODE or
InfoObject Name
0TCTNODE Account Name From Source Data
0TCTATYPE Type of Hierarchy Authorization 0 4
0TCTHIEVERS Hierarchy Version Initial or Version
0TCTACOMPM Area of Validity Hierarchy Authorization 0 3
0TCTTLEVEL Hierarchy Level Initial or Level
0TCTOBJVERS InfoObject Version A Active
0TCTSYSID BW System ID Initial or System ID
0TCTADFROM Begin of Validity 19000101 or Source
0TCTNDEF Default Value of Node Initial

Each data record that is loaded into one of the Data Store Objects includes a value, interval or a
hierarchy node for which a user is to be authorized.

23



For the generation itself, you assign the associated authorization object(s) to the Data Store Objects
and then execute them. To automate the generation use transaction RSECADMIN or report
RSEC_GENERATE_AUTHORIZATIONS.

A detailed log is created during generation that documents the generation steps. Old logs can be
viewed from the transaction RSECADMIN under the Analysis tab page, Generation Logs or at the start
of the report RSEC_GENERATE_AUTHORIZATIONS by clicking on the log symbol.

Comparison of Various Maintenance Methods

24

Business Content Roles
Some Business Content Roles have only menus with the attached workbooks, but not authorizations.
These roles are typically designed for reporting users. Other Business Content Roles may contain user
menus as well as authorizations. These types of roles are commonly designed for administrator users.

Templates
Templates enable you to easily insert a set of authorizations into a role. These are maintained in
tcode SU24 and used in the Authorizations portion of role maintenance (tcode PFCG).

The following is a list of few SAP-provided templates:
o S_RS_RDEAD: Administrator on Development System
o S_RS_ROPAD: Administrator on Production System
o S_RS_RREDE: Reporting Developer on Development System
o S_RS_TICUM: Maintain InfoCube
o S_RS_TICDM: Maintain InfoCube Data

Note: SAP provides templates that you will need to bring into your roles; & not the roles.

You can view or build new templates using tcode SU24. Once you are in the authorization portion of
the roles (tcode PFCG), the Choose Template window will appear automatically if the Menu is empty.
Otherwise, choose Edit Insert Authorizations From template, to integrate a template into a role.
After inserting the template, you can update, insert, and delete authorizations as needed.

Comparison of Authorization Concept



The report RSEC_MIGRATION supports the manual conversion of old Reporting Authorizations to the
new Analysis Authorization concept. After the migration, the newly created Analysis Authorizations
may have to be further edited or partially remodelled. Customer-exit variables for 0TCTAUTHH cannot
be migrated; the respective hierarchy nodes must be assigned manually. This is a Singular event, not
for scheduling. During migration to the new authorization concept, the existing concept won't be
changed.

All users assigned to a Reporting Authorization will be affected by the migration, so only complete
user groups can be successfully migrated.

The authorization objects S_RSJCUBE, S_RS_MPRO, S_RS_ISET AND S_RS_ODSO are no longer
checked during query processing. The check is now performed on new Business Content InfoObjects:
0TCAIPROV, 0TCAACTVT and 0TCAVALID. These InfoObjects are provided during migration, and are
25

generated according to the entries in the InfoProvider and Activity fields from the original
authorization.
Migration Methods
There are three methods available for migration to the new Analysis Authorization concept.
1. Direct Assignment Using this method, authorizations are assigned directly to the users. The
assignment is made based on the original profiles, however, no roles or profiles are created
during the migration. Use transaction RSU01 to check or change the user and profile
assignment if necessary.

The migrated authorizations appear as generated authorizations in RSECADMIN. This method
is particularly suitable for smaller installations or for the first simple tests.

2. Generation of New Authorization Profiles With this option, new profiles are created during
the migration process. A different profile is generated for every authorization and is then
assigned to the users. The generated profile includes an authorization for the new
authorization object S_RS_AUTH, with the technical name of the Analysis Authorization as the
value.

The generated profiles have a technical name that begins with RSR_ and is followed by an 8
digit number. These profiles are assigned to the same users as the original migrated profile.

The role authorization concept is maintained and built parallel to the original. This method is
useful if the role concept is maintained. This method is also useful if the old Reporting
Authorizations exist in separate profiles that need to be removed after migration.

3. Enhancement of the Existing Profiles This method enhances existing profiles with new
Analysis Authorizations using the authorization object S_RS_AUTH.

When a profile is re-generated in role maintenance, PFCG, the inserted entries from the
migration could be deleted. Also, when the migration is repeated with another option, the
entries are emptied, but the authorization stays the same. In this case, traces of the
authorization may remain but do not have any authorization function.

The application log is displayed directly after the program has run in interactive mode. Or as
an alternative, you can go into transaction SLG1 and choose RSEC_BW_AUTH as the object
and MIGRATE as the subobject. The log reports success and error events during the
migration.

It is possible, if necessary, to undo the migration, rendering all previous migrations ineffective. The
associated generated BI authorizations and profiles are deleted and the entries for authorization
object S_RS_AUTH are removed. To undo a migration, use the Undo Migration option in Tcode RSEC
MIGRATION.















26

Unit #8: Authorizations for Business Planning & Simulation

There are two planning tools in BI:
o BW-BPS (Business Planning and Simulation)
o BI Integrated Planning, a solution that is completely integrated into the BI system.

Both planning tools use the same data basis and can be operated in parallel in one system. It is not
necessary to migrate existing planning applications.

The Planning Modeler for BW-BPS is transaction BPS0. Use transaction RSPLAN to access the
Integrated Planning modeler. This transaction links to the web-based tool. A planning wizard is also
available for Integrated Planning.

There are delivered authorization templates for Integrated Planning:
o S_RS_PL_ADMIN Planning Administrator
o S_RS_PL_PLANNER Planner
o S_RS_PL_PLANMOD_D Planning Modeler (Development System)

The portal is required to use BI Integrated Planning. A portal role is required to use the Planning
Modeler: [Link].businessylanning_showcase. This role is found in the Portal Content Directory
(PCD).

Unlike BW-BPS, the new solution is completely integrated into the BI system. This allows you to build
integrated analytical applications that contain planning and analytical functions. Therefore, it is
recommend to use the BI integrated planning structure to implement new scenarios.

The authorizations that users require for BI Integrated Planning are basically the same authorizations
they require to analyze the data in a query. In addition to the authorization for displaying data, the
authorization for changing data is also required in the analysis authorizations.

The system checks authorization object S_RS_COMP which contains the activity Execute. Query or
planning function may use AggregationLevel, MultiProvider or Real-time InfoCube as an InfoProvider.
But the analysis authorizations should not vary from Aggregation Level to Aggregation Level defined
on the same InfoProvider. Hence the authorizations are defined for the InfoProvider on which the
aggregation level is based. Aggregation levels are transparent as far as analysis authorizations are
concerned.

Variables are one-dimensional. That's why there is potential mismatch of multi-dimensional selections
and automatically filled variables (of type authorization). This is especially relevant with planning
because there are typically authorizations on characteristics combined with different activities. E.g.


A variable of type authorization on country filters for all countries (DE,AT, CH,DK) in the example. If
at the same time change authorizations are required for a planning query, the authorization check
fails because of missing change authorizations for DE and AT. However, the query would not fail
completely but switch to display mode. The filtering could be refined with a variable of type
customer-exit which reads the complete authorization information and filters the country based on
the activity.




27

Plan Query Approach

The query contains a structure with two elements where the elements contain a key figure and are
restricted by version. This definition internally triggers two sub-queries; one for reading the data to
be displayed and one for the data to be changed. If the user has authorizations to change plan data
and display actual data, this query works for this user.



In the following example the authorization check fails because change authorizations for actual data
are checked.



BW-BPS Authorization Objects
Authorization objects of the planning framework
o R_AREA Planning area
o R_PLEVEL Planning level
o R_PACKAGE Planning package
o R_METHOD Planning method
Hint: The authorization for local sequences is covered by the planning method (R_METHOD).
All local sequences have the fixed method '0-BF'.
o R_PARAM Parameter group
All authorization objects have the following activities
o 02 Change
o 03 Display
o 16 Execute (except for planning package)
o 21 Transport

Lower-level authorization Objects inherit authorizations from higher-level authorization objects. E.g. If
user has authorization for the Execute activity for a planning level, they may also execute all functions
and layouts that were defined for the level.
28



Hierarchical Structure
R_AREA Planning area
- R_PLEVEL Planning level
- R_METHOD Planning method
- R_PARAM Parameter group

Other authorization objects for planning are listed here
R_PROFILE Planning profile
R_BUNDLE Global planning sequence
R WEBITF Web Interface Builder
R_PM_NAME Planning folder
R_STS_CUST Customizing STS (Status and Tracking System)
R_STS_SUP Special access to STS
R_STS_PT Planning session and subplan

In contrast to reporting which is usually always possible, in planning, data changes should not always
be possible. Instead they should only be possible at certain times or under certain conditions. This is
about enabling access at certain times and then changing the settings so that no access is possible.

Access restriction with authorization methods
Changing authorizations
Changing the activity in BW reporting authorizations from 'change' to'display'.
Deleting the authorization for executing a user interface, like with a planning folder.
Deletion of authorization for executing planning objects such as layouts or functions.

Independent of authorizations, the following restrictions can be made.

Access restriction with other methods
Data areas can be protected using data slices. The data slices can be made user dependent
using variables.
Status and Tracking System (STS), automated access restriction (similar to workflow).
The values for a variable can be restricted (removed).

Creation of a data slice protects the specified area against changes. The STS controls access with
hierarchical dependency. For example, if your superior has approved data that has already been
planned, the data cannot be changed.

Which of these methods can or should be used and when depends on various factors. One decisive
factor is how much effort is required for the changes to be made and how often these changes have
to be made.

Authorization Methods Frequency of Changes Complexity and Effort
Reporting authorizations Low High
Authorization for planning
objects such as function
Low Medium
Data Slices Medium Medium
Value set of variables Medium -
User interface authorization Medium Low
Status and Tracking System High Medium

Frequency of Changes
Low by Planning Session or Longer
Medium within a Planning Session or Week
High within one Day

29

Unit #9: Appendices

Performance Recommendations
1. The authorizations and typical query selections should be designed in the same way. E.g. If
the query is typically filtered by single values, then authorizations should also be defined
using single values. If intervals or hierarchy nodes are used for selection, the authorizations
should be defined in the same way using intervals or hierarchy nodes.
2. Cardinality of authorization checks The number of authorization checks that take place is
affected by the following factors, which also each multiply based on the order of magnitude.
The factors are
Number of authorization-relevant characteristics
Number of authorized values
Number of authorization objects
Scale of authorization checks = (average # values) x (average # characteristics) x (#
authorization objects)

In some cases, the scale of effort required for authorization checks should be even higher.
E.g. When a user has multiple authorizations for an authorization object that cannot be
combined into one authorization & thus, require checks on the single value combination level
(cartesian product of authorized values).
Scale of authorization checks = (# values characteristic I) x (# values characteristic 2) x ...

Multiple Authorizations, Not Combinabale


If a performance problem occurs, you could also consider assigning more authorizations. i.e.
combining both authorizations into one superordinate authorization or full authorization (*) to
the user if requirement permits.

Multiple Authorizations Enhanced / Combined


30


An automated authorization generation specific to structural authorizations from mySAP ERP Human
Capital Management to SAP BI is possible. As a prerequisite, the data that you want to protect has to
be located in a hierarchical structure of a personnel development component (organization
management, personnel development, event management, etc.)

Advantages
Maintenance is easier because authorizations are changed accordingly when there are
structural changes
Clear
Limitation
Structural authorizations are very powerful, thus the following aspects should absolutely be
considered:
In addition to structural authorizations, the general authorizations could also be used, which
means mapping the structural authorizations in SAP alone may not be sufficient.
Authorization requirements in SAP can be different from those in the source system so that
the standard mapping of Business Content may not fulfil the requirements.

Procedure
A prerequisite is that structural authorizations are already created. If not, then these should
still be done as part of the mySAP ERP HCM project.
There are appropriate objects for this in Business Content with which the structural
authorizations can be loaded (DataSources, InfoSources, DataStore Objects). These should
be activated.
Scheduling data loading
Scheduling or manual execution of generation as with the automatic generation scenarios
that were already introduced

The following steps are necessary to provide the required data in BI.
The users for which authorizations were extracted should be entered into the table T77UU
(user data are kept in the SAP memory this way)
Generation of indexes using the report RHAUSOO in the INDX index cluster.

The DataStore Object 0PA_DS02, due to its structure and function, corresponds to the DataStore
Object 0TCA_DS01 (the general template for generation of value authorizations) and 0PA_DS03
corresponds to 0TCA_DS02 (hierarchy authorizations).

As for the general case of authorization generation, the following steps must occur:
The associated characteristics have to have been defined relevant to authorizations in BI for
the organization structures (for example OORGUNIT).
The data has to be loaded into the DataStore Objects accordingly.
The generation for an authorization object that includes the associated authorization relevant
characteristics has to take place.