Authorization
An authorization is the empowerment to carry out a certain activity in the Business Information Warehouse. Each authorization refers to an authorization object and defines one or more values for each field that is contained in the authorization object. Individual authorizations are summarized into authorization profiles by system administration. You can copy the roles delivered by SAP and adjust them when you want. The system administrator creates these authorizations and enters them into individual users’ master records in the form of profiles.
The authorizations in the Business Information Warehouse are based on the standard SAP authorization concept.
Types of functions of authorizations
With authorization checks, any functions or objects in the system can be protected. With an authorization check, when you perform a certain action, the system compares the values for the individual fields of an authorization object that are assigned to the user, with the values that are provided for the execution of an action in the program. A user is only authorized to carry out an action if the authorization check has been successful for every field in an authorization object. In this way, complex checks of the user authorization can be carried out.
You need different authorizations to work with the Administrator Workbench and the Business Explorer.
Authorization Profiles for Working with the AWB
As an administrator, you will need special authorizations in the Business Information Warehouse and in the source system, which you can determine in the user settings.
You need the following authorization profiles for the administrator’s tasks:
In the Business Information Warehouse:
S_RS_ALL (Business Information Warehouse: All authorizations) In the source system:
S_IDOC_ALL (All authorizations for IDoc functions) B_ALE_ALL (All authorizations for ALE/EDI authorization objects) S_A.CUSTOMIZ (Customizing [for all activities with system setting]) Scenario
For documents for transaction data, you want to assign display authorization for certain documents to users. You do not want the users to be able to edit or delete the documents.
For the authorization check for documents for transaction data, you use reporting authorization objects that you can create and edit in Transaction RSSM (RSECADMIN as of Release 7.0). First, the standard procedure (regardless of the Support Packages) is described below:
Display authorization for documents
To be able to display a document, you require the authorization for the corresponding data. If a document is assigned to customer 1000 and material ABC, for example, you require authorization for the combination of these characteristic values. You also require at least authorization ":" for aggregated data for all other authorization-relevant InfoProvider characteristics.
You also require the colon authorization if the "Characteristic is document property" option (in RSD1) is NOT set for an authorization-relevant characteristic. (For more information about the colon authorization, see Note 727354).
For documents without an InfoProvider assignment, the system checks all authorization objects (or more precisely, all authorization objects activated for any Info-Provider). This usually applies to documents that are created using SEM BPS. However, in the case of documents that are assigned to an Info-Provider,the system only checks the authorization objects that are activated for this Info-Provider.
Caution: If, for a reporting authorization object, you have assigned the * authorization to a user in each field, this authorization is not checked (optimization). This means that the user also has maintenance authorization for documents in the corresponding data area. If you want to use this type of authorization to assign only display authorization for documents to users, you must include the Activity authorization field (ACTVT) in the authorization object and fill it with the value "Display" (03).
Maintenance authorization for documents
There are two ways of assigning maintenance authorization for documents.
1. Only using the reporting authorization objects:
This is the recommended procedure, but it may be rather time consuming if authorizations already exist (see below). However, we strongly recommend that you use this procedure for new projects.
To be able to differentiate between displaying and maintaining (documents) for the reporting authorization objects, you must also include the Activity authorization field (ACTVT) in the authorization object. Caution: To do this, you must first delete all authorizations for these objects as well as the profiles and roles in which they are used.
You can add this field in Transaction RSSM in the same way you add characteristics to the authorization objects. Use the "Display" (03) or "Enhanced maintenance" (36) values for this field. In this context, "Enhanced maintenance" means the maintenance of documents. In the authorizations for this object, you can then combine the characteristic values with the values for the activity as required.
In this way, you can assign maintenance authorization tousers for a specific data area while in other areas, the users are only allowed to display documents.
Caution: In this case, the user must not have maintenance authorization for documents via the "Administrator Workbench Object" object (RSADMWBOBJ).
2. Using reporting authorization objects in combination with the S_RS_ADMWB authorization object:
To minimize the time spent on maintenance, you can assign maintenance authorization to a user for all documents that the user can display according to the logic described above. In addition to the reporting authorizations for the "Administrator Workbench Objects" (S_RS_ADMWB) authorization object, assign the following authorization to the user for this:
Administrator Workbench Object (RSADMWBOBJ) Documents for transaction data (DOC_TRAN) "Activity" (ACTVT): Maintain (23)
If you do this, all documents that can be displayed based on the reporting authorizations can also be changed by the user. The advantage of this variant is that you do not have to delete existing reporting authorizations.
Example
Example for Meta and Master data authorization in a role Some default authorizations need to be assigned such as for RFC communication etc
Meta example
Via S_RS_ADMWB, display authorizations have been provided for all infoobjects Via S_RS_IOBJ, all authorizations have been given for infoobject 0CALMONTH
Master Example
Via S_RS_IOMAD, change authorizations have been given for all infoobjects. Via S_TABU_LIN, display authorizations have been given for values 01.2003- 02.2003
Infoprovider Example
Via transaction RSECADMIN
- SAP Managed Tags:
