Authorizations

Authorizations

ASAP for BW Accelerator

Business Information Warehouse

Methodology on how to analyse and design authorizations.
(Description)
Document Version 1.0

Table of Contents

1Introduction......

2Guidelines......

3MACROROLES...... 3

4Authorization specification and design tasks during the BW

project...... 4

4.1 Business Blueprint...... 4

4.2Realization...... 4

4.3Final preparation...... 4

5Authorization requirement collection approach...... 6

5.1infocube based approach...... 6

5.2query name based approach...... 6

5.3infocube independent dataset approach...... 6

6The authorization accelerator...... 7

1998 SAP America, Inc. and SAP AGTable of Contents

Authorizations

1Introduction

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.

2Guidelines

  • 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 system (for monitoring and loading) / S_RS_ROPOP
BW REPORTING DEVELOPER / S_RS_RREDE
BW REPORTING USER / S_RS_RREPU

4Authorization 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.1Business 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).

  • 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.

4.2Realization

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.3Final preparation

During the final preparation you have to test the authorizations for the initial set of queries.

FIG. 1 – maps of authorization related tasks

FIG. 2 – authorization tasks and templates in the ASAP for BW Roadmap

Phase / Tasks / Template
Project preparation
Business Blueprint / Role identification / PI-Documentation Template allows you to add also access restrictions to characteristics relevant for each role.
First identification of the authorization relevant characteristics
Definition of an authorization strategy / Please refer to this paper as a guideline and share the approach with the customer.
Realization / 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

5Authorization requirement collection approach

Here we describe three compatible approaches to collect the authorization requirements.

5.1InfoCube 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.2Query 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.3InfoCube 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.

6The 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 1 of 7