In order to interact with SAP Commerce Cloud, a user needs certain privileges. There are a number of permission mechanisms available that can be combined to provide the right access for a user. Although configuring these individual permissions is straightforward, the combination of the all options can cause issues in projects. This guide has collected some recommended practices for the setup of users and permissions.
Table of Contents
Projects typically focus on the storefront and every aspect of the customer's experience. The accessibility for the business users is often overlooked and postponed until the end of the engineering phase or even the application management phase. This impacts the general acceptance of the system as key users and business users require additional unnecessary time to test and use the system.
You have various options to set up the user permissions. The combination of these different options requires a structured setup of user roles and fine-grained rights. Projects that postpone the setup of the permissions to the application management phase suffer from the fact that the application management team often does not have the knowledge and capabilities to set up the permissions in a structured way; the setup of users, roles and permissions becomes a messy area and does not satisfy the business users' requirements as the fine-grained options are not being leveraged properly.
The various options that can be used to set up the user permissions are shown in the figure below.
This document focuses on the user management of business users and does not (yet) cover specific details on customers, specifically in a B2B solution.
User Groups and Inheritance
Like any system, permissions and access can be provided by assigning a role or group to a user. In SAP Commerce Cloud roles and groups are a flexible concept and are provided by user groups. A user can be assigned to multiple groups, but more important groups can be nested. Nesting user groups is an important capability since the access rights and other accessibility features can be setup with inheritance in mind. The user group hierarchy is, therefore, an important aspect of the setup.
The image below shows a simple example of such a hierarchy. The user in this setup is assigned to the productmanagergroup which provides access to all the relevant pieces. The permissions are driven by direct access from the user (sync permissions), permissions granted from the direct role (productmanagergroup) and the inherited permissions from the employeegroup.
The figure above shows a simplistic version of most organizations. It is quite common for users to not have full access to the complete set of catalogs (different departments), to all languages (translators), as well as the ability to publish content straight to the online world (synchronization). A more fine-grained setup is required in order to develop personalized permissions that are manageable and will not cause contradictory permissions.
The example below shows a setup with group inheritance for a global company with maintaining multiple sites for different sales organizations. This example illustrates a number of recommended practices:
- Permissions should never be granted to individual users, as this will not scale easily.
- Reuse of out of the box roles is recommended and should be used as a starting point of the group hierarchy.
- The cockpit group should be inherited to enable specific functionality across all the cockpits.
- Access rights should be assigned high up in the inheritance tree.
- Catalog read and write permissions should be separated from access rights and should be organized per sales organization or any other market group (i.e. Germany vs France). This will allow different users to have different responsibilities for the content without duplicating access rights.
- Business tools views should be organized high up in the hierarchy so that all underlying users will benefit from it unless there are specific requirements for underlying roles.
- reader and manager groups are typically used to allow organizations to grant read and/or write access to the system.
- Only write permissions should be granted to Staged catalog versions to avoid unexpected changes in the online version.
- Synchronization permissions should be explicitly granted by specific usergroup.
- Language permissions should not be granted high up in the hierarchy, otherwise, the permissions will be granted to all underlying users.
SAP Commerce Cloud ships with a number of standard usergroups. Most of those roles provide standard access rights that can be leveraged in projects to be up and running quickly. A few usergroups are important, as they play a basic role in the system:
The admingroup is initialized during the initial system setup and cannot be removed. Users assigned to the admingroup will not be restricted and have access to the Administration Console. The admingroup should not be given to business users. It should only be used for technical administrators, as the permissions allow the ability to change the system drastically.
The employeegroup is not mandatory in the system, but is used by all standard modules and is, therefore, the recommended root for all employee usergroups.
The cockpitgroup is used by cockpits (i.e. productcockpit, cmscockpit) as a root type for showing user groups and users in the so-called "query" dialog. It is best practice for employee usergroups to inherit from the cockpitgroup so that they have full access to cockpit features.
Type system permissions
Access rights are used to define permissions for data items in SAP Commerce Cloud. Every item is of a specific composed type will likely have several attributes. Permissions can be granted for both the type as well as the individual attributes. Access rights can be setup on both user level as well as usergroup level. It is recommended to define access rights on usergroup level so that permissions can be shared among multiple users.
Permissions can be granted, denied or not specified (neutral). If the permission is not specified the permission will fallback to the inherited access rights on the parent group(s). Since a user can be assigned to multiple groups and groups can be organized in a hierarchical structure, the access rights can cause conflicting permissions; conflicts occur if one group grants permissions for a specific item type and another group denies the permissions for the same type. SAP Commerce Cloud will prioritize denials for access rights defined on the closest inheritance level. Moreover, when two permissions are conflicting on the same level, the denial is prioritized. This is visualized in the figure below.
The figure below depicts a scenario where conflicting access rights have been set up in different groups in the hierarchy. SAP Commerce Cloud will grant access to the user since the access right is positive in the closest group.
Conflicting permissions are very hard to fix and are often faced when the project is in production. In order to prevent conflicting permissions, the best practice is to avoid denials by default.
SAP Commerce Cloud Portal Access
As outlined in Getting Started with SAP Commerce Cloud, SAP Commerce Cloud comes with a self-service Cloud Portal which provides several features related to managing your SAP Commerce Cloud environments. Access to the Cloud Portal is governed separately from the groups discussed above. Users are managed within the Cloud Portal as covered in the documentation as well as in this video.
This article introduces you to the fundamental challenges of User Management. SAP Commerce Cloud offers a wide range of capabilities concerning user management, roles and rights management. Different strategies can be implemented to define the organization and roles of your company, but once one is chosen, you should stick to it to avoid conflicting permissions. Now you know what you should consider if you want to setup structured user roles and fine-grained rights.
The following article will help you dive deeper on Access Rights You may also be interested in Roles and Permissions Workshop, which can help walk you through the options for roles and permissions in your organization.