Access Control Management: Access restrictions explained – Access Context
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:
- Basics of access control and business roles
- Access Control Management: Access restrictions explained – Access Context (this blog)
- 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
- Special Access Control Topics
The previous blog mentioned that each object is controlled by the access context. This access context is a characteristic of the work center view/business object. In the following screenshot, you can see that the work center view Account has the access context 1015 – Employee or Territory or Sales Data.
The access context 1015 is also relevant for Opportunities, Sales Quotes and other business objects. Other business objects such as the product may have different access contexts assigned. The access context is a characteristic bound to the work center view/business object. It is defined by the standard set up of the business object and cannot be changed or enhanced. Hence the access control capabilities for a certain business object works in the defined structure of the access context. That also implies – if there is no access context defined for a work center view/business object a distinct instance base access control setup is not possible for that particular entity.
For custom BOs created with the SAP cloud development studio access control can be inherited from a standard business object through association. In addition it is also possible to define a custom BO specific access control context related to employees or territories.
Example for Access Context:
The work center view “Accounts” has the access context 1015 assigned (Employee or Territory or Sales Data). This implies that the access to an account can (only) be controlled based on the following criteria:
EMPLOYEES directly assigned in the account team –> I have access to all accounts where I am member of the account team (independent of the role assigned); or my manager has access to all accounts of EMPLOYEES of the functional unit (organization) for which he is assigned as a manager.
TERRITORY team –> I have access to all accounts which are assigned to a territory I am a member of. Accounts assigned to territories which are sub territories of my territory are also accessible. Please note that the work center territories where the territories can be maintained works with a different access context – 1010 Employee!
SALES DATA – This is a capability introduced with 1508 –> I have access to all accounts which are assigned to a sales area I am eligible for. The assignment of my relevant sales areas can be maintained in the employee master independent of my actual organizational assignment.
For customers who started to use the system prior to the introduction of sales area in the access context. A scoping option was introduced to ensure compatibility with the access behavior before. That compatibility mode is active for those customers by default and ensures that the sales area access restriction is only effective for accounts with either an account team member or a territory assigned. For customers who started to use the system after 1605 the compatibility mode is not active by default – an account w/o territory and account team member is accessible only when the sales area matches.
This scoping option can be reached in the Business configuration (Built-in service and support –> System Management –> User and Access Management –> Compatibility mode for Access Context 1015 – “Do you want the Access Context 1015 – sales area restriction to be effective only for objects with employee or territory assignments”.
In some cases it might happen that an account is initially created and hence has no access restriction relevant data maintained such as a directly assigned employee or a territory (aka homeless object instance or unassigned data records).
In this situation the system is not able to determine on how to restrict access for a certain user on this account. Here the system is designed to react access tolerant and it will provide access to the object instance by default. This behavior is also relevant for other business objects.
If that is not desired it is possible to change the default access behavior of the system in scoping (scoping option available since release 1702). This option allows to not show object instances w/o any restrictive content (unassigned data records)
Business Configuration –> Scoping Element: Built-in Service and Support –> System Management –> User and Access Management: Tick question “Do you want in general restrict access to data records that do not contain any access relevant content”.
If this option is set the “Compatibility mode for access Context” 1015 should not be activated, otherwise the authorization restriction would not be considered for data records which only have sales area data maintained.
Read/Write access can be restricted on Work Center View (Business Object) level.
Consider the following scenario for account Widgets Inc.:
For Widgets, Inc, Violet is assigned as the owner of the account. She is the designated employee responsible. Violet’s business role provides access context to accounts by employee. Violet’s business role provides her only access to accounts that are owned by Peter.
The question is: Can Violet see the account Widgets, Inc?
The answer is no: Violet cannot see it because access context outweighs the role employee responsible. Even though she is the employee responsible, her access restriction settings in the role assigned to her only provides access to accounts that are owned by Peter.