Welcome to the blog series on access control management in SAP Hybris Cloud for Customer (C4C). The series discusses various access control topics in C4C. The goal of this blog series is to provide a complete overview on the access control concept and capabilities in C4C and to let you know on how it works in detail.
Here are the blogs of that series:
I have already explained in the previous section how to proceed to analyze when the access control results are not as expected. With 1805 some additional analyzing capabilities for the administrator had been provided which further help to analyze the access control behavior. Here I describe how the new feature works. The explanation is a bit lengthy (sorry for that) but it is worth to read and to understand it.
The 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 feature is accessible through the Work Center Administrator --> General Settings --> Check User’s Authorization.
The tool requires the business user and a business document instance (for example a customer ID, opportunity ID, sales quote id…) as input parameter (actually it is in addition required to specify what kind of business object need to be analyzed).
Based on this information the tool 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.
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 it contains the data which are checked against the user’s access control setup. In case of matching entries, access is granted.
In my example I have entered a customer ID “PACH31058” and selected the business object type “Business Partner”. Let’s understand now the details of the data:
The window is structured by the different access contexts which are a characteristic of the business object (by standard definition). The business partner in my 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) hence we have several access context details listed.
That is the technical ID (UUID) of the instance as it is identified in the data base. That technical number is basically not relevant for the administrator and can most likely be ignored.
Mini Gross is maintained as Employee Responsible in the account team. This is why she is listed in the ACL as an access relevant entry. If other employees in other roles would be assigned to the account team, we would also see them listed here.
[Sales Data] S1000 --> Germany Frankfurt
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. Hence the ACL contains an entry for each valid combination.
The account is assigned to one territory “33 – Germany other States” as the territory is also access relevant in the access context 1015 it is listed in the ACL.
With the ACL data of the customer we have just one half of the data relevant to calculate the access. The other missing part are the access control settings for the business user. These are now listed in detail under the tab User Access.
This tab shows the entire access settings of the selected user. The access settings are usually resulting from the assignment of the user to the business role. The user in my example has among others the work center view "Accounts" assigned, 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:
That is the technical user ID and the user’s alias name
This indicates that the user is not assigned as a substitute for another users. Substituting other users and by that temporarily inherit other users access rights can be managed by the administrator (see also the blog “Special Access Control Topics - Delegates”)
WOCView Accounts Restricted Read and Write
The work center views the user has assigned through its business role are now listed. Underneath the work center view the data are depicted for which that specific user has access to. The structures listed here are depending on the restriction rule chosen in the access restriction for the work center view in the business role (in my example the restriction rule was Territories, Employees (for Managers)).
In my example the following accounts can be accessed:
The tab “Document” is just a different representation of the information also shown under the tab “Document Access”. Here the data are just presented in a table structure (this tab is a remaining from the original UI of the check user’s authorization).
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 BAdI CustomAccessControlListWrite (for details please check the 1802 What’s new documentation and the SAP help portal).
The BAdI can be implemented through the SAP Cloud Studio (aka SDK or PDI). This provides a higher flexibility to specify customer specific access control. Further business objects with the capability to adjust the ACL might follow.
The section “Determined Authorization Details”, shows the ACL entries as determined by the customer specific logic implemented in the BAdI, whilst the section “SAP Standard Determination Authorization” still shows the ACL entries how they would be determined through standard logic. The effective ACL however in this case is the ACL as determined by the BAdI logic.
Here are the blogs of that series:
- Basics of access control and business roles
- Access Control Management: Access restrictions explained - Access Context
- Access Control Management: Access restrictions explained - Restriction Rules
- Access Control Management Example: Global versus local admin
- Access Control Management Example: Access forwarding
- How to analyze access control issues
- How to analyze access control issues - Check User's Authorization (this Blog)
- Special Access Control Topics
I have already explained in the previous section how to proceed to analyze when the access control results are not as expected. With 1805 some additional analyzing capabilities for the administrator had been provided which further help to analyze the access control behavior. Here I describe how the new feature works. The explanation is a bit lengthy (sorry for that) but it is worth to read and to understand it.
Check User's Authorization
The 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 feature is accessible through the Work Center Administrator --> General Settings --> Check User’s Authorization.
The tool requires the business user and a business document instance (for example a customer ID, opportunity ID, sales quote id…) as input parameter (actually it is in addition required to specify what kind of business object need to be analyzed).
Based on this information the tool 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 it contains the data which are checked against the user’s access control setup. In case of matching entries, access is granted.
In my example I have entered a customer ID “PACH31058” and selected the business object type “Business Partner”. Let’s understand now the details of the 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 my 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) hence we have several access context details listed.
07773E028B341EE296F842D0853B7777
That is the technical ID (UUID) of the instance as it is identified in the data base. That technical number is basically not relevant for the administrator and can most likely be ignored.
[Employee] 602629 --> Mini Gross
Mini Gross is maintained as Employee Responsible in the account team. This is why she is listed in the ACL as an access relevant entry. If other employees in other roles would be 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. Hence 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” as the territory is also access relevant in the access context 1015 it is listed in the ACL.
With the ACL data of the customer we have just one half of the data relevant to calculate the access. The other missing part are the access control settings for the business user. These are now listed in detail under the tab User Access.
User Access
This tab shows the entire access settings of the selected user. The access settings are usually resulting from the assignment of the user to the business role. The user in my example has among others the work center view "Accounts" assigned, 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
That 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 another users. Substituting other users and by that temporarily inherit other users access rights can be managed by the administrator (see also the blog “Special Access Control Topics - Delegates”)
WOCView Accounts Restricted Read and Write
Access Context 1015
The work center views the user has assigned through its business role are now listed. Underneath the work center view the data are depicted for which that specific user has access to. The structures listed here are depending on the restriction rule chosen in the access restriction for the work center view in the business role (in my example the restriction rule was Territories, Employees (for Managers)).
In my example the following accounts can be accessed:
- All Accounts, which have the Employee 602629 Mini Gross assigned in the account team
or - As Mini Gross is a manager of Org Unit S1000, all employees assigned to that org unit and assigned to the account team.In case the "Resolve Hierarchy" flag is checked, the report shows all the org substructures including the employees assigned. Try that out to get the full picture.
Document
The tab “Document” is just a different representation of the information also shown under the tab “Document Access”. Here the data are just presented in a table structure (this tab is a remaining from the original UI of the check user’s authorization).
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 BAdI CustomAccessControlListWrite (for details please check the 1802 What’s new documentation and the SAP help portal).
The BAdI can be implemented through the SAP Cloud Studio (aka SDK or PDI). This provides a higher flexibility to specify customer specific access control. Further business objects with the capability to adjust the ACL might follow.
The section “Determined Authorization Details”, shows the ACL entries as determined by the customer specific logic implemented in the BAdI, whilst the section “SAP Standard Determination Authorization” still shows the ACL entries how they would be determined through standard logic. The effective ACL however in this case is the ACL as determined by the BAdI logic.
- SAP Managed Tags:
2 Comments
| User | Count |
|---|---|
| 5 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
