Security Overview

There are multiple components to security. There are BW specific roles needed to do things on the BW
application server (execute queries, etc…). BOBJ has security for what can be done (execute reports /
modify reports / etc..). HANA has security itself, etc… We’ll most likely add on to this as well go.

To start, we’ll talk just about the BW security piece.

BW Security:

There is a security role which puts a nice front end on this. However, we don’t have access to this in
production. So it’s worthwhile to know the back-end tables as it’ll help you diagnose production
support issues.

Main BW Security Tables:

AGR_USER – User and assigned roles
AGR_1251 – Roles definitions (what is included in that role)
AGR_AGRS – Composite role definition

AGR_USERS:
Definition:

Data:
Note:
This user has 43 roles assigned. Note the dates range associated with each role. So even if the user has
a role in the table, it might not be effective anymore. This table is very to see what roles people have.
For example, a user XXXX indicates they can’t run a report but their co-worker YYYY can. You can lookup
both users (XXXX and YYYY) in this table and see what roles each has. If there is a difference, you’d need
to investigate the different roles to see if one of them contains access to the desired report. If so, then
you’d know the user needs to get access to a specific role to be able to execute the report.

AGR_1251:
Definition:
Data:

Note:
This is where the detail of each role is. This role has objects, fields, and values (low and high fields). For
the list of objects, see the link below. The objects you’ll be using mostly are the S_RS_COMP and
S_RS_COMP1. The sub-objects (field column) you’ll mostly be interested in are RSINFOAREA,
RSINFOCUBE, and RSCOMPID. RSINFOAREA and RSINFOCUBE are the highlighted areas below. So
RSINFOAREA will gran access to the InfoArea. I think of this as the logical grouping. RSINFOCUBE needs
to be the multi-provider or cube/dso your query is built off of. RSCOMPID is going to be the query which
gets executed. These used to be the exact query name. Now they are the query area, but not specific
query number (see ZEG_ZGEMR_M01_PQ* in the above example).

So let’s take the example of adding a new DSO, multi-provider and query. Before anyone would be able
to access this in production, you’d need to modify a role with the new Query (RSCOMPID records), cube
(RSINFOCUBE), and possibly object group (RSINFOAREA).

Another example would be a new report on an existing multi-provider. Presumably then, the
RSINFOAREA and RSINFOCUBE objects are already there (you need to validate this). Then all you need
to add is the new query (RSCOMPID). If there is already the generic query name present, you won’t
need to do anything. If only exact query names are present, you’d need to add either your new query or
add the generic query name (as illustrated in the example above).

Note: there is a ‘deleted’ column. So you’ll only want those records where are still active.

For your reference… Here are all the security objects and the sub-objects of each (along with
values). This will dictate the values in table AGR_1251.
Objects:
http://wiki.sdn.sap.com/wiki/display/SMAUTH/Authorization+Objects+Overview
S_RS_COMP1 and sub-objects:
http://wiki.scn.sap.com/wiki/display/SMAUTH/S_RS_COMP1

AGR_AGRS:
Definition:

Data:

Note: This example illustrates a composite role that has three child roles attached. If a user request the
composite role added, they’d then get all three child roles added to their profiles. This is basically a
shortcut to be able to add one common role instead of many for a common job (ie developer, report
analyst, etc..).