Name: Understanding Custom Access Rights in SAP Commerce Cloud
Uploaded: 2024-4-19
Duration: 719 s
Description: In this video, you will learn about custom access rights, a security feature which allows you to restrict the access to specific users or users groups based on specific criteria.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div>In this video, you will learn about custom access rights, a security feature which allows you to restrict the access to specific users or users groups based on specific criteria.<br></div></div></div>

Understanding Custom Access Rights in SAP Commerce Cloud

Hello everyone. In this video, we're going to talk about the security feature Custom Access Rights.  Before we begin, let's review some access rights basics in SAP Commerce Cloud.  First, let's review type-based access rights.  These are the standard, out-of-the-box kind of access rights granted on SAP Commerce types and their individual attributes to a principal.  In SAP Commerce Cloud, a principal is a User or UserGroup.  A type-based access right applies to all items or instances  of a composed type.  Access cannot be granted to some items but not others.  These access rights are enforced automatically and system-wide via the perspective layer. Example given, they have immediate automatic effect in Backoffice cockpit.  Finally, individual attributes or entire items will be essentially invisible to the user to whom access is denied. Allow me to demonstrate. I created an employee in the system and enabled his Backoffice login.  When we click the key icon which opens the access right management for this employee, we can see all the types the user has access to on the left pane, and each type's individual attributes on the right.  Now, if we add a permission for this employee to access the catalog type,  then this user will be able to see the attributes of all catalog items.  But please note we cannot pick and choose which individual items this applies to.  With the help of search restrictions we can address this limitation.  Let's review this feature.  Restrictions also known as personalization rules  or more formally as search restrictions can filter which items of a type that can be accessed by users.  The restrictions filter is inserted automatically into all underlying flexible search statements.  An example, are those that involve that user and the restricted type at execution time.  A search restriction requires three elements, namely, on what type the access is restricted, the principle to whom the access is restricted, an example, a user or a user group.  And the where clause predicate.  This is the filter condition we mentioned earlier.  Let's check out a predefined restriction as an example.  Here we restrict access to the product type.  The restriction will be applied to Customer Group,  that is all members of the user group.  And the filter restricts, in example, making visible all product items whose ApprovalStatus is not equal to the specified Enum items pk here.  This is the condition for visibility.  If we put these all together, the restriction defines that customers can only see products whose approval status is approved.  Technically speaking, a restriction is a condition added to the Where Clause of the SQL statement produced by the flexible search executed during runtime.  And it has a system-wide effect.  Let's check out another demo to understand this further.  I'll first go to Catalog and see there are more than two items.  Then I'll navigate to the system, personalization node,  and create a new electronicsProductCatalogRestriction  and apply on Sohail.  I specifically filter as id like electronicsProductCatalog  and specify catalog as the restricted type.  If this employee were to log in to Backoffice,  he would see only the catalog that passes through the filter specified in the restriction.  So much for the review.  Let us explain custom access rights.  They allow you to define arbitrary privileges.  With them, you may define your own permission types that can mean whatever you want them to mean.  You can grant or deny permissions to types, attributes, item instances,  or abstract operations.  Allow us to demonstrate there is no Backoffice navigation node for this type, so I'll have to search items by type.  In System, Types, I search for permission,  which reveals the commerce type of UserRight with an English label of user permission.  If I open the type UserRight for edit, I can click the magnifier icon to search by type,  which lists all UserRight items.  From the item editor view, I can create a new custom UserRight with an identifier of test permission and click finish.  However, be careful not to overuse this feature. Because your arbitrary custom permission is not meaningfully understood by commerce, it cannot be automatically enforced.  Your code will need to invoke methods from PermissionCheckingService to enforce your custom permission everywhere it applies.  This typically creates quite a maintenance and testing burden for the developer.  Also, managing and checking permissions at the item level can considerably degrade performance since a huge number of items can be involved.  Wherever possible, use the out-of-the-box type-based permissions and restrictions.  Here is the API that allows checking of global, item, and type permissions.  An item permission is checked by PermissionCheckingService  via the checkItemPermission method.  This method takes as parameters the checked item, the principal,  and the permission name, so that we can check whether the specified principle has the specified permission to the item.  Let me demonstrate this in the HAC Scripting Languages console  where we can access the API via a Groovy script.  First we obtain references to the test user and the electronics BaseStore.  Then we can use PermissionCheckingService to check whether the test user has been assigned to the read permission on the electronics BaseStore.  Let us see another API example.  To create an item permission, we call permissionManagementService. createPermission  passing a permission name as the parameter.  To assign an item permission to a principal, we first need to create a new PermissionAssignment object,  which relates to a specific permission ID to the principal.  In this case, the read permission and the principal are combined via a new PermissionAssignment object.  Then, I call the addItemPermission method to associate the permission assignment object with the item, so that the principal now can be granted the read-write to the specific item.  Let us check this code example here.  We have programmatically created an educationPermission and obtained references for the user and BaseStore, which we will need later.  Then, we instantiate a new permission assignment object,  which combines the newly created permission with the user in preparation for the next step.  Here, false means granted, which seems backwards to many people,  so be careful.  Then we associate the permission assignment with the BaseStore  via the addItemPermission method.  Finally, we check whether the item permission is assigned and we expect the method to return true.  In addition to item level permissions, the API also allows us to manage attribute-level and type-level level permissions.  To add a type-level permission, invoke the method addTypePermission.  It accepts the parameters Type and PermissionAssignments.  To check whether the permission has been assigned, we call the checkTypePermission method.  We can create attribute-level permissions via the addAttributePermission method,  passing the specific Attributes and PermissionAssignment as parameters.  We would check the same via the checkAttributeDescriptorPermission method. Let us look at another example in the HAC.  Here, we first obtain a reference to the Type from the typeService via its code BaseStore.  Instead of a string literal, we're using the static typecode constant from BaseStoreModel.  We again create educationPermission and get the test user via its UID.  Websites is the attributes display name in the BookStoreModel type, which we see here in the Backoffice.  If we check the corresponding locales properties file, it is the localization string for the attribute declared as cmssites.  We get this attribute descriptor for the cmssites attribute of BookStoreModel via typeService.  We will need this later, so bear with me now.  Let's go back and create a new PermissionAssignment object with the test user and the created permission.  Then we call the addTypePermission method to assign the test user,  Sohail, the educationPermission for the BaseStore type.  In the next line, we can verify whether this permission has been granted, and it returns true.  Similarly, for the attribute, Website, we can assign the permission to the test user, Sohail.  On the next line, we can check whether the test user, Sohail, is granted educationPermission on the specific attribute  and it should again return true.   Finally, let's talk about global permissions.  Global permissions are assigned to principles and don't pertain to targets like items, types or attributes.  They can also be used as a fallback or default assignment that is the lowest priority which is always overridden by item, type  or attribute permission assignments.  You can define any permission as a global permission  which includes the predefined read or write etc.  or any custom permission you can imagine which we discussed before.  Let us examine this in HAC.  Let us obtain a test UserGroup via its UID from userService  and the BaseStore with UID electronics.  Before applying any changes, we can check whether this test user group has read access to this BaseStore.  Of course, it will return false for now.  Let us create a permission assignment object which has read access granted to the test UserGroup.  This PermissionAssignment will be passed to the addGlobalPermission method to be added via permissionManagementService.  Now let us check again whether the test user group has read access to BaseStore. The result is now true as the test user group has the global permission assigned to read the BaseStore.  Now that you understand the custom access rights, let's talk a bit about their limitations.  First, permissions granted by custom access rights are fully abstract.  Thus, they cannot be automatically enforced.  This means your code must invoke a method or two  from the PermissionCheckingService to enforce the permission explicitly everywhere it applies.  Also, by default, only the Media Management SecureMediaFilter uses item- based custom access rights.  Second, permission assignments are calculated and not stored as items.  Hence, it's not possible to search for the effective permission assignments via Flexible Search Queries.  Example given, it's not possible to query for all items that have a permission xyz granted for the principal P.  Third, permission assignments are currently not represented by models, so you cannot directly import them  using ImpEx scripts, as we do with regular type-based permissions. If you want to import a custom permission assignment, you'll need to use the PermissionManagementService in ImpEx via bean-shell scripting.  Thank you for watching.