In contrast to analysis authorizations, which control access to data content, object authorizations provide access protection on an Object level, like Table or InfoProvider. Object authorizations are required by all users to be able to access certain tables or InfoProviders at all.

Note, however, that only the general access to tables or InfoProviders is covered. There is no access restriction to the data contents of these providers. Access to the data content is controlled via analysis authorizations. These authorizations allow you to provide certain data contents for users. Thus a fine-grained assignment of authorizations is possible.

Imagine an InfoProvider with information about different company codes. The object authorizations determine whether you can access the InfoProvider at all. The analysis authorizations allow you to view information about a specific company code. For example, you may be allowed to see the sales of company code A, but not of company code B.

Object authorizations in SAP BW

Object authorizations provide access protection at the InfoProvider level. These authorizations are required by all users, for example to call queries and model data. This involves general access to InfoProviders. There is no access restriction to the data contents of these objects.

The object authorizations are modeled in SAP BW using authorization objects. These are used to control access. For example, the authorization object S_RS_ADSO is required to work with contents of an ADSO.

In addition, the analysis authorizations are often required, because usually at least the InfoProvider itself is authorization relevant via the InfoObject 0TCAIPROV.

In the next chapter you will find  recommendations for the standard SAP object authorizations.

Recommendations for standard Object Authorizations

ADSO

If you work with an ADSO, you need the object authorizations via the object S_RS_ADSO. In addition to the Name of the DataStore object, you must also specify the relevant InfoArea. You can use the Activity field to restrict the functions that a user can execute. In order to change the contents of the ADSO, the user needs the activity 23 Maintain.

In the Subobject for ADSO field you should select DATA to access data.

InfoObject

If you want to maintain InfoObjects in addition to ADSOs, you need the authorization object S_RS_ADMWB to be able to display InfoObjects. Please make sure the Display activity is set for the administrator workbench object InfoObject.

In BW4/HANA Object S_RS_ADMWB is not needed anymore. Access to the respective InfoObject is granted via the authorization object S_RS_IOBJA.

If you are still using InfoObject Catalogs, you need to use the Auth Object S_RS_IOBJ instead. 

DDIC Table

No additional object authorizations are necessary. The user should be able to access the table via NextTables authorization /NLY/TBLS though. This authorization object is explained in the next chapter. 

Object Authorizations for NextTables

Once you install NextTables, a new authorization object is created - /NLY/TBLS. This authorization object is exclusively related to the use of NextTables. All object authorizations for NextTables are covered by this object.

This authorization object covers certain access types via the respective authorization field. Four authorization fields are defined:

• /NLY/APP - Unique Application ID
• /NLY/TTYPE - Table Type
• /NLY/TNAME - Table Name
• /NLY/ACTVT - Activity

Under /NLY/APP you enter the name of the application that you created during setup.

In the authorization field /NLY/TTYPE you define the table type. You can choose between the following entries:

• DDIC    Data Dictionary Table
• DSO DSO (Advanced or Classic)
• CUSTOM Custom (e.g. Views, etc.)
• IOBJ_ATT    InfoObject Attribute
• IOBJ_TXT    InfoObject Text
• ALIASTABLE   Alias Table

In the /NLY/TNAME field, enter the name of the table to be accessed.

With the authorization field /NLY/ACTVT you can control which activities are allowed when accessing the table. The following options are available:

• R     Read
• W     Write
• A      Admin role (create configuration)
• C     Content Admin role
• S      Super Admin (can set Customizing of the NextTables application)

The activity R allows to display a table, while the activity W allows to edit (insert/edit/delete) a table. Users with activity R are therefore only allowed to read the tables, whereas users with activity W are allowed to edit the tables.

There are also three admin roles for the administration of NextTables. Super-Admin (S), Config-Admin (A) and Content Admin (C). The roles will be explained further below. (<- hier section nach unten verlinken). 

Recommendations for NextTables Object Authorizations

Using the authorization fields described you can define your authorization setup for each application in a very flexible way. Please take into consideration that the Read permission (ACTVT ‘R’) must be always included for all users for the respective Application that users will need to have access to. That is because the menu application is based on the Read permissions of the respective user. Therefore, if no Read permission for any Application is granted the user won’t be able to see any of the applications developed within NextTables.

Furthermore, it is also recommended to set up an Config Admin user, at least in the development system. This user should have full permissions.

On the production system, however, all ad-hoc changes to Configurations should be typically avoided. Therefore, this role should only be assigned to a limited number of people.

Examples regarding Authorization Setup

Finally, we would like to illustrate the authorization concept with a few examples.

Suppose you want to create an internal role for operation control. The user with this role should be able to see and edit all tables in the production environment. But he should not be able to include new tables or change the configuration.

To achieve this goal you can proceed as follows. Create two different roles: an Operation Control role and an Admin role. The Operation Control role is assigned on all systems and should be defined as follows:

The admin role, on the other hand, is only assigned on the development system and is set as follows:

With this approach you will achieve the following. You will be able to create, edit, import and delete data within the tables on both systems. Also you will be able to configure NextTables like the themes or the Welcome Page, since neither of them can be transported. 

It will be checked whether the user has authorization for administration (activity A) of the respective application. The user can create, save and adjust his own templates. To save the created template globally and thus make it available to all users, activity C (Content Admin) is also required. However, read access to the configuration tables is still available for persons with the operational control role.

In the development system, users have additional permissions via the admin role, e.g. to be able to include and new and configure existing tables, menu entries or apps.

Consider also the following examples:

In the example we have assumed that the employees always have the appropriate authorisation (S_RS_ADSO / S_RS_ADMWB).

NextTables version 9 and later provides a configuration and menu wizard. We strongly recommend using the wizards. The process is guided, quick, easy and less error prone. Please have a look at “How to configure NextTables” for more information.

Admin Role Overview

Recommendations for organizing Applications

While the tables integrated in NextTables increase rapidly, the overview in the menu decreases significantly. A coherent structure for the application and menu entries is necessary to keep track of 100 or more entries. 

It is possible to stack applications and keep the individual authorizations of each stacked application. 

Example: The controlling department maintains the budget for Personal and Material Costs. The responsible person from the controlling department should be able to see and maintain both tables. The users of the d

epartment Human Resource and Purchasing should be able to see and maintain only the necessary tables. 

Menu Structure:

Authorizations:

Scenario 1: User sees full menu structure

A controlling user could have the Roles CO_TOP, CO_PC, CO_MC and would see all three applications. 

A HR User could have the roles CO_TOP and CO_PC and would be able to see only the Menu Entry for Controlling and Personnel Costs and the tables within the menus. 

Scenario 2: User sees only his menu

The controlling user could have the Roles CO_TOP, CO_PC, CO_MC and would see all three applications like in scenario 1.

The HR User would only get the role CO_PC and therefore only the Personnel costs menu would be visible. 

With this neat trick you can mix and match applications and authorizations for different user groups. Since the activities read, write, content and config admin are always bound to an application it is possible to have only read access to App_A,  read and write access to App_B and be content admin of APP_C. The menu structure helps to organize the applications in Next tables, but it does not influence the authorizations. 

Which License is needed for this feature Professional ✔ | Enterprise ✔