Name: Working with Authority-Based Restrictions in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-4-14
Duration: 528 s
Description: In this video, you will learn about widget authority-based restrictions with an application orchestrator.

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><div><div><div><div><div>In this video, you will learn about widget authority-based restrictions with an application orchestrator. </div></div></div></div></div></div></div></div>

Working with Authority-Based Restrictions in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Lily. In this video, we'll discuss widget authority based restrictions with an application orchestrator. The back office framework provides the ability to build authority based restrictions into an application user interface and authority in back office framework is analogous to a business user rule. Technically, authority based restrictions are implemented in conjunction with authority groups within back office. An authority group is a special kind of group of type back office roles. A user that is placed into an authority group will automatically assume the privileges of the authorities designated for that authority group. Authority based restrictions are implemented at the widget level, as each widget instance has its own restriction settings. Note that this restriction capability is separate from the SAP e-commerce platform, permission setting, and restrictions that are automatically integrated into back office, such as type based permission. By default, when you add a new widget to a cockpit, any user with a login to the application will be able to see that widget. If you would like to limit which authorities can view a widget, you can specify that in the widget settings. With authority based restrictions, you can build entire cockpits and mashups that are specific to one or more authorities. When users log into the application, they only see the cockpits and widgets that they have permission to view based on the authority groups to which they belong. Let's for demonstration of how to configure widget visibility for different authority groups. Each user can be assigned to multiple authority groups. Each authority group can have multiple authorities, although in this case each group has exactly one authority. For the purpose of this demonstration. I previously set up a system with some authority groups and users. Simple Group has the authority authority. Simple advance group has the authority authority. Advanced. The users that were created for this demonstration are called simple, advanced and multi. Here you can see that the user simple belongs to the simple group. The user advanced belongs to the advanced group. The user multi belongs to both authority groups. When you have a user that belongs to more than one authority group, that user must choose an authority group. Upon login. A select group pop up will be shown for that. This is because the application displays the view for just one authority group at a time. To a user. The user can switch authority groups at any time after login, and the application will dynamically update to display the view for the selected authority group. To begin adding authority based restrictions to your application. An administrator or application orchestrator needs to log in and set up the restriction. There are two ways to add restrictions to a widget instance. The first way is by going directly to a widget instance. Settings and adding the authorities in its Access Restrictions tab. The second way is by selecting an authority group from the application's authority Group selector box, and then adding widget instances. First, I'll show you how to add a restriction to a specific widget instance through its settings. For example, let's say that I want to add restrictions to the editor area instance. I want only the authority simple authority to be able to view this editor area. To do this I'll go to the settings for the editor area instance. Then I'll switch to the Access Restrictions tab. Here I'll add our desired restriction by specifying the authority for the simple group. Authority. Simple. Note that if you have more than one restriction that you would like to add, just separate them by commas. Now only the users that belong to authority simple are allowed to view this widget for all other users. This widget is invisible. Now that we have set up our restriction on the editor area widget instance, let's refer back to the users we created for this demonstration. According to this diagram, the users simple and multi should be able to see the editor area instance because they both have the authority simple authority. The user advanced shouldn't be able to see the editor area instance. Let's confirm this. I'll login to the application as simple. We can see that the user simple is able to see editor area widget instance as expected. Next I'll log in as advanced to confirm that this user can't see the editor area instance. As you can see, the user advanced isn't able to see the editor area widget instance. Now I'll demonstrate the second way to add restrictions. This is the way that allows you to use Application Orchestrator to build an entire widget mashup for a specific authority group. I'll log in as an administrator and go to Application Orchestrators mode. I'll select advanced Group from the list of available authority groups. While this is selected, any widget instances and connections between them that we add will be restricted to authorities that belong to advanced group. I'll add a new widget instance that only users in advanced Group will be able to view. I'm going to add an output test widget instance. I'll also connect the previously existing collection browser instance with our newly added output test instance. Now that we have set up a small up with a restriction to the advanced group, I'll refer back to the users created for this demonstration. As you can see, the users advanced and multi should be able to view the output test widget instance because they're both in the advanced group. The user simple shouldn't be able to see this widget instance. Let's confirm this. I'll start by logging into the application as advanced to verify that this user can view the output test widget instance. As you can see, the output test widget instance is visible for the advanced user. Now along into the application as the user multi. Because multi belongs to multiple authority groups, this user will need to select an authority group upon login. We'll be able to see how the visibility of widgets changes for this user depending on which authority group is selected. At login we select the advanced group authority group. So we're expecting that the user will be able to see the output test widget instance. As expected, the output test widget instance is visible for the user multi. Now without logging out from the application, we can change the authority group to simple group. The output test widget instance doesn't include simple group in its restrictions, but the editor area instance does. So we're expecting the simple user to see the editor area instead of the output test instance. As you can see, the editor area widget instance is visible for the user multi. When the authority group is changed to simple group, the output test instance isn't visible for this user. When simple group is selected as the authority group. This concludes our demonstration of how to configure authority based restrictions within application Orchestrator. Thanks for watching.