You can restrict access to the data of an operational data provider (ODP) for analysis purposes. For example, you can configure a user to have restricted access to the order item data of an ODP (based on the product ID and business partner ID). In general, you model authorization checks in the operational data provider (ODP) for which you want to restrict data access.
You model ODP authorization checks by either using authorization objects or access control lists (depending on the authorization concept in your application). These are based on DataSources that contain a field for the user. Authorizations for navigation attributes are modeled using access control lists (ACLs).
Software component ESH_COMMON_OBJECTS is in your application-specific software component.
If you want to model authorization checks for a search and analysis model delivered by SAP, make sure that there is a customer-specific software component that includes the SAP software component which contains the search and analysis model.
More information: Creating or Adapting a Search and Analysis Model
If you model the authorization check using ABAP authorization objects, the relevant application provides the necessary authorization objects.
If you model the authorization check using access control lists, the relevant application provides the necessary access control lists.
Modeling Authorizations
Proceed as follows:
Go to the Response of Node step in the search and analysis model, which contains the ODP for which you want to restrict data access.
Here you define the authorization check for the ODP. You use either authorization objects or access control lists (depending on the authorization concept in your application). Authorization objects are used by default.
In the Structure screen area, select the node belonging to the ODP for which you want to specify an authorization check.
Go to the Authorization tab page.
Using Authorization Objects
Go to the ABAP Authorization Objects tab page.
You must first import an authorization object before you can use it to model an authorization check. Press the Import button. Next, enter a name for the authorization object and choose Import.
Choose Add to create a new row for the authorization check.
Enter a name for the authorization check in the Check ID field of the new row. Enter a description in the Description of Check ID field.
Select the authorization object in the ABAP Name of Authorization object field and confirm your entries.
To specify the values for the authorization object fields, select the check and go to the Details: Fields of Authorization Object ('Object Name') screen area. The following values are relevant here:
Dynamically obtained value from a node attribute (ODP field) at runtime:
To select the node attribute with the required value for an authorization field, choose Select Path in the relevant row.
A dialog appears. First select the node and then the relevant node attribute.
The system adds the Target Attribute field to the relevant row in the detail area.
A target attribute is basically the attribute with product IDs.
Fixed Value:
Enter a fixed value in the Value column. You can also enter several values separated by semicolons.
You can enter the fixed values 02;03 for the attribute ACTVT, to allow query access for the node (ODP) for which the user has display and change rights.
Save the model.
Using Access Control Lists
We assume that a DataSource is defined for an ACL and the DataSource contains a field for the user, to make sure that information on user assignments is available. Proceed as follows:
Save your search and analysis model and return to the initial screen of search and analysis modeling.
Create a new search and analysis model (in your software component) that is based on the DataSource defined for the ACL.
Import the DataSource in the Model Node. In the Details screen, choose SAP User ID in the Semantics column for user field of the DataSource (USER_ID).
Create an ODP for the node in the Operational Data Provider step.
Save your model and return to the initial screen of search and analysis modeling.
Open the model again that contains the ODP, which you want to model the authorization check on.
In the Node Relationships step, add an association to the root node of the model that you have just created for the ACL DataSource. Keep the cardinalities suggested by the system.
Define the foreign key relationship by going to the root node of your model ( Attributes of Higher Level Node) and selecting the attribute to be checked for the user (for example, product ID attribute). Under Attributes of Lower Level Node, select the relevant attribute of the ACL model root node.
In the 'Response of Node' step, go to the
tab page.Choose Add to create a new row for the authorization check.
Enter a name for the authorization check in the Check ID field of the new row. Enter a description in the Description of Check ID field.
You can specify the attribute that the system checks for at runtime for a user by defining an authorization path:
Choose Select Path in the relevant row.
A dialog box appears. Expand the node in the Models and Nodes screen area and select the node for the ACL DataSource.
In the Details screen area, the User ID checkbox is selected for the user attribute of the ACL node. To create the path, select the user attribute and press Select.
The row for the authorization check now displays the authorization path in the Reference Node field and the user attribute is displayed as the Target Attribute.
Save the model.
Once you have defined all the authorization checks for the ODP, create a logical conjunction for the authorization checks using the analysis authorization type (in the lower area of the Authorization tab):
Every authorization check, regardless of whether it uses authorization objects or access control lists, must be contained in the logical conjunction.
You define the logical expression using these two operators: & (AND), | (OR). You can also use brackets. The operator - (NOT) is not supported by the authorization type Analysis.
Save the model.
Special Case for Navigation Attributes: Modeling Authorizations
Proceed as follows:
In your master data model, the navigation attributes are maintained in the ODPs, for which you want to model the authorization check. In addition, the navigation attributes are added to the relevant transaction data model.
Create a new search and analysis model (in your software component) that is based on the DataSource defined for the ACL.
Import the DataSource in the Model Node. In the Details screen, choose SAP User ID in the Semantics column for user field of the DataSource (USER_ID).
Create an ODP for the node in the Operational Data Provider step.
Save your model and return to the initial screen of search and analysis modeling.
If you have more than one ACL to display referencing fields (sending cost center and receiving cost center, which both reference 'cost center'), then create the relevant ACL models. We recommend that you use a descriptive naming convention for the models so that you can differentiate between the various fields.
Open the master data model again and configure the following settings:
In the Node Relationships step, add an association to the root node of the model that you have just created for the ACL DataSource. If you have more than one ACL model, then add the relevant associations. Keep the cardinalities suggested by the system.
Define the foreign key relationship by going to the root node of your model ( Attributes of Higher Level Node) and selecting the attribute to be checked for the user (for example, product ID attribute). Under Attributes of Lower Level Node, select the relevant attribute of the ACL model root node.
Save your master data model and return to the initial screen of search and analysis modeling.
Open the relevant transaction data model and configure the following settings, to add the authorization checks (defined using ACLs) to the model:
In the Response of Node step, go to the tab page.
Choose Add to create a new row for the authorization check.
Enter a name for the authorization check in the Check ID field of the new row. Enter a description in the Description of Check ID field.
If several ACLs are used for different referencing fields, we recommend that you use a descriptive naming convention so that you can differentiate between the referencing fields.
You can specify the attribute that the system checks for at runtime for a user by defining an authorization path:
Choose Select Path in the relevant row.
A dialog box appears. Expand the node in the Models and Nodes screen area and select the node for the ACL DataSource.
In the Details screen area, the User ID checkbox is selected for the user attribute of the ACL node. To create the path, select the user attribute and press Select.
The row for the authorization check now displays the authorization path in the Reference Node field and the user attribute is displayed as the Target Attribute.
Once you have defined all the authorization checks for the ODP, create a logical conjunction for the authorization checks using the analysis authorization type (in the lower area of the Authorization tab):
Every authorization check, regardless of whether it uses authorization objects or access control lists, must be contained in the logical conjunction.
You define the logical expression using these two operators: & (AND), | (OR). You can also use brackets. The operator - (NOT) is not supported by the authorization type Analysis.
Save the model.
Testing Authorization Checks
To test the authorization checks you have modeled, proceed as follows:
Create a test user, which either has a profile with the relevant authorization objects or which is part of the user ID values in the relevant access control list.
The test profile user does not need the authorization object S_RS_AUTH.
However, if the profile contains S_RS_AUTH, check that the user does not have the * value for S_RS_AUTH. Otherwise, the user has all analysis authorizations.
Create a query with the authorization-relevant characteristics in the drilldown. You can also use variables for the test.
Use transaction RSUDO to run the query as a test user with transaction RSRT.
You can view the test logs by using either transaction RSUDO or RSECPROT.
For information on the runtime behavior of authorization checks, see Authorizations in the Analytic Query