Authorizations
ASAP FOR BW ACCELERATOR
BUSINESS INFORMATION WAREHOUSE
Methodology on how to analyse and design authorizations.
(Description)
Document Version 1.0
SAP (SAP America, Inc. and SAP AG) assumes no responsibility for errors or omissions in these materials.
These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the
implied warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages
that may result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within
these materials. SAP has no control over the information that you may access through the use of hot links contained in these
materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party
web pages.
AUTHORIZATIONS
Table of Contents
1
INTRODUCTION ........................................................................................................... 3
2
GUIDELINES ................................................................................................................. 3
3
MACROROLES ............................................................................................................. 3
4
AUTHORIZATION SPECIFICATION AND DESIGN TASKS DURING THE BW
PROJECT ...................................................................................................................... 4
4.1 BUSINESS BLUEPRINT ................................................................................................. 4
4.2 REALIZATION............................................................................................................. 4
4.3 FINAL PREPARATION .................................................................................................. 4
5
AUTHORIZATION REQUIREMENT COLLECTION APPROACH ................................. 6
5.1
5.2
5.3
6
INFOCUBE BASED APPROACH .....................................................................................
QUERY NAME BASED APPROACH .................................................................................
INFOCUBE INDEPENDENT DATASET APPROACH.............................................................
6
6
6
THE AUTHORIZATION ACCELERATOR...................................................................... 7
1998 SAP AMERICA, INC. AND SAP AG
TABLE OF CONTENTS
AUTHORIZATIONS
1 Introduction
In this paper we describe a project approach for the BW authorization requirements
collection and for the corresponding and strictly linked authorization design and
implementation.
2 Guidelines

Start to consider the authorization requirements as soon as possible during the project.

Keep the requirements as simple as possible. Complex authorization requirements imply
complex authorization design and some administration workload for the authorization
maintenance.

Develop an authorization strategy.

Establish appropriate name ranges.
3
MacroRoles
We can identify several categories of BW users. From now on these categories will be
called “MacroRoles”. For each MacroRole there‘s a standard template to be used.
Anyway here we discuss more in depth the reporting users, because their requirements
are customer specific and they need to be collected in a structured way during the project.
At a rough level we can identify the following MacroRoles (at the right you can find the
corresponding BW standard template to be used as a starting point):
MACROROLE
BASIC TEMPLATE
BW DATA MODELER
S_RS_RDEMO
BW SYSTEM ADMINISTRATOR(S)
Administrator of
development system
S_RS_RDEAD
Administrator of
productive system
S_RS_ROPAD
Operator of productive S_RS_ROPOP
system (for monitoring
and loading)
BW REPORTING DEVELOPER
S_RS_RREDE
BW REPORTING USER
S_RS_RREPU
PAGE 3 OF 7
AUTHORIZATIONS
4 Authorization specification and design tasks
during the BW project
Here we describe which are the authorization linked tasks in the different ASAP for BW
phases. In figures 4.1 and 4.2 you can find a summary of these tasks.
4.1
Business Blueprint
During the Business Blueprint phase there are three tasks concerning authorizations:

Role identification. For example you identify “accounting manager” and “sale responsible”
as two significant roles in your BW project.

First identification of the authorization relevant characteristics. Before the final data
model design and for each role, you can collect some needed limitations on data access
such as “the sale responsible can see only his own sales area data”.
These two aspects are covered in the PI-Documentation-Paper which is a template for the
Business Blueprinting. (Please check for existing Accelerator).

4.2
Definition of an authorization strategy. You have to identify a consistent approach to
authorization requirement collection and you have to choose which level of detail is
needed and which level of administration workload you can support. In paragraph 5 we
describe more in depth some possible approaches.
Realization
In parallel to data model implementation you can start one after the other the following tasks:

the detail authorization requirements collection;

the authorization design (reporting object, authorization and profiles design);

the authorization implementation.
4.3
Final preparation
During the final preparation you have to test the authorizations for the initial set of queries.
PAGE 4 OF 7
AUTHORIZATIONS
FIG. 1 – maps of authorization related tasks
Role identification, first requirements
Strategy
Authorization requirements
collection
BW authorization
requiremets collection
Authorization design
template (with
suggested design
rules)
for
authorizations
Implementation
Test
FIG. 2 – authorization tasks and templates in the ASAP for BW Roadmap
Phase
Tasks
Template
Project
preparation
Business
Blueprint
Realization
Role identification
First identification of the
authorization relevant
characteristics
PI-Documentation Template
allows you to add also access
restrictions to characteristics
relevant for each role.
Definition of an
authorization strategy
Please refer to this paper as a
guideline and share the approach
with the customer.
Collection of
authorization
requirements at the
chosen level of detail
Authorization requirement and
design suggestion template
(Excel)
Profile design
Authorization
implementation
Final
preparation
Test of authorizations
Go live and
support
PAGE 5 OF 7
AUTHORIZATIONS
5 Authorization requirement collection approach
Here we describe three compatible approaches to collect the authorization requirements.
5.1
InfoCube based approach
You can collect the requirements allowing or not allowing for specific InfoCubes. If it‘s
convenient, you can use the concept of InfoArea to allow or not for a group of InfoCubes
belonging to the same InfoArea.
You can go in a more detail if you limit the accessability of a cube, allowing only for a part of
it. We can name dataset the Sub-InfoCube which is limited by the authorizations assigned to
a user. In BW a dataset can be defined according to characteristics, key figures, hierarchies
and their combinations.
5.2
Query name based approach
For pure reporting users (not allowed to build new queries) you can use the query names to
simplify the authorization design, creating specific queries for specific roles and allowing only
certain query names. The disadvantage of this approach is that there‘s no relationship
between query name and set of data, so new queries are potentially security dangers.
5.3
InfoCube independent dataset approach
Before the data model you don‘t know the InfoCubes, but you can express authorization
requirements through data set, i.e. limitations on to characteristics, key figures, hierarchies
and their combinations at various level of detail.
PAGE 6 OF 7
AUTHORIZATIONS
6 The authorization accelerator
The authorization accelerator (file name „BW authorization requirements template.xls“)
allows you to:

Collect the authorization requirements for specific roles (one Excel per Reporting User
Role)

Choose the best authorization approach and modifying consistently the template

Choose the right level of detail concerning the complexity of the requirements
The accelerator:

hides the complexity of the authorization requirement collection if this is not needed

links an example for each template sheet.

Although it is focused on the requirement specification, for each object (e.g. Infoareas,
Infocubes, queries, …) the accelerator gives the corresponding implementation
suggestions.
Here‘s the initial screen:
PAGE 7 OF 7