Overview

Understand how the "Check User's Authorization" functionality works and the benefits of analyzing access control issues.

Table of Contents

Overview

In the previous article, it was explained how to analyze the system when the access control results are not as expected.

As of the 1805 release, to help with analyzing the access control behavior, some additional analyzing capabilities for the administrator have been added.or.

This article describes how this feature works. 

Check User’s Authorization

The "Check User's Authorization" feature provides some detailed information on how the access control settings for the relevant business user and a selected business object instance (for example, a customer ID) are defined.

Comparing the access details of both entities can help to find potential discrepancies in the access control setup and to correct them accordingly.

The "Check User's Authorization" feature is accessible through the following path: Administrator –> General Settings –> Check User’s Authorization.

This feature requires the business user and a business document instance (for example, a customer ID, opportunity ID, sales quote id) as an input parameter.  It is additionally required to specify what kind of business object needs to be analyzed.

Based on this information, this feature will then provide detailed information on the access control data of the business document instance and the access control settings for the related business user.

Analyzing these results helps to identify the reason for an unexpected access control behavior.

Document Access

Let’s start with the access control details for the business document instance. These details are exposed under the tab “Document Access”.

The window shows the data of the so-called access control list (ACL) of the business document instance.

The ACL is a structure associated with the business document instance and contains the data that are checked against the user’s access control setup. In case of matching entries, access is granted.

In the below example, you can see the selection is customer ID “PACH31058” and the selected the business object type is “Business Partner”.

Now, let’s understand the details of the sample data:

• Access context 1015
  • The window is structured by the different access contexts which are a characteristic of the business object (by standard definition).
  • The business partner in the example is access controlled through the access context 1015 (providing the access structure by Employee, Sales Data and Territory).
  • The business partner can also be access controlled through the "Partner" work center views (access context 2004) and the "Competitor" work center view (access context 2009). Therefore, we have several access context details listed.
  
  
• 07773E028B341EE296F842D0853B7777
  • The above is the technical ID (UUID) of the instance as it is identified in the database. That technical number is basically irrelevant for the administrator and can be ignored.
  
  
• [Employee] 602629 –> Mini Gross
  • Mini Gross is maintained as an "Employee Responsible" in the account team. This is why she is listed in the ACL as a relevant access entry.
  • If other employees in other roles were assigned to the account team, we would also see them listed here.

• [Sales Data] S1000                   –> Germany Frankfurt
• [Sales Data] S1000; 01             –> Germany Frankfurt, Direct Sales
• [Sales Data] S1000; 01; 01       –> Germany Frankfurt, Direct Sales, Division 01
  • Account sales data are maintained for the Sales Area Germany Frankfurt, Direct Sales, Division 01.
  • Any combination of the sales area such as Sales Org, Sales Org + Distribution Channel, Sales Org + Distribution Channel + Division is access relevant. Therefore, the ACL contains an entry for each valid combination.

• [Territory] 33 –>  Germany other States
  • The account is assigned to one territory, “33 – Germany other States”. This territory, listed in the ACL, is also access relevant in the access context 1015.

User Access

With the ACL data of the customer, we have half of the relevant data to calculate the access. The other missing part is the access control settings for the business user. These are now listed in detail under the "User Access" tab.

This tab shows the entire access settings for the selected user. The access settings usually result from the assignment of the user to the business role.

The user, in our example, is assigned to the work center view “Accounts” which comes with the access context 1015.

The access context 1015 is structured by employee (and its organizational assignment), territory and/or sales data. Here is how to understand the data shown:

• User JYU9R2PSM0Z         Alias MGROSS
  • This is the technical user ID and the user’s alias name.
  
  
• User is not substituting other employees
  • This indicates that the user is not assigned as a substitute for other users. Substituting other users and temporarily inheriting other users access rights, can be managed by the administrator (see also the article on Special Access Control Topics – Delegates).
  
  
• WOCView        Accounts        Restricted Read and Write
  Access Context 1015
  • The work center views, assigned to the user through her business role, are now listed. Underneath the work center view, the user's data access is depicted. The structures listed here depend on the restriction rule chosen in the access restriction for the work center view in the business role. In this example, the restriction rule was Territories, Employees (for Managers) and the following accounts can be accessed:
    • All accounts where Employee 602629 Mini Gross is assigned to the account team can be accessed.
    • Or, since Mini Gross is a manager of Org Unit S1000, all employees assigned to that organizational unit as well as to the account team can access the accounts. In case the “Resolve Hierarchy” flag is checked, the report shows all the organizational substructures including the employees assigned.

Document

The tab “Document” is just a different representation of the information shown under the tab “Document Access”.

Document Access – Determined Authorization Details

In some exceptional cases, the ACL data of a business object are shown in this section.

For some business objects (for example, Sales Quote, Opportunity) it is possible to adjust the ACL entries through customer-specific logic implemented in the Business Add In (BAdI) CustomAccessControlListWrite. The BAdI can be implemented through the SAP Cloud Applications Studio (either through Software Development Kit or Partner Development Infrastructure). This provides greater flexibility in specifying customer specific access control.

The section “Determined Authorization Details”, shows the ACL entries as determined by the customer-specific logic implemented in the BAdI. The section “SAP Standard Determination Authorization” shows how the ACL entries are determined through standard logic. The effective ACL however in this case is the ACL as determined by the BAdI logic.

Conclusion

This article introduced you to the feature "Check User's Authorization" and explained how it works, in case you face access control issues.

Now, you know how to proceed next time you face some issues.