Regarding the Smart Devices Architecture, actions programmed by GeneXus users are translated into REST calls in general.
The procedures called inside user actions are automatically set as REST Web Services.
In this paper we show how to manage permissions taking this fact into account.
We also show how to group permissions to make the permissions management easier.
In case you program a call to a procedure from an Panel for Smart Devices, Dashboard Object, or Work With Pattern for Smart Devices the procedure is automatically set as a REST.
If you want to make this object private (the execution of the object) as well as the procedure itself, you need to take into account that the REST web service needs to be protected also (independently from the SD object).
Suppose in this case that you have an SDpanel which lists all the "Literary Styles" an editorial works with, so the SD panel layout consists on a grid where the "Literary Styles" are loaded using a dataprovider programmed by the GeneXus user.
Figure 1. SD panel which loads data using a dataprovider
In the SD panel grid we have an action where the user can subscribe to receive any news about the selected "Literary Style", so the grid has an action in each line, and the SDpanel´s complete code is as follows:
Figure 2. SD panel which includes an action in each line of the grid, and the code assoaciated to it
1. The procedure "SubscribetoNovels" is exposed as rest web service automatically, when you specify the SD panel object. See the properties of the procedure in the following figure.
Figure 3. REST Procedure properties
2. The dataprovider used to load the grid with the "Literary Styles" is not set automatically as REST, and doesn´t need to be exposed as it. The difference is that the dataprovider is called from a server side event, and the procedure is not. See Start and Load Events in Smart Devices for details.
Solution to the problem exposed
The goal is to make these objects (SD panel and procedure) private and make GAM to check that the final user has permissions to execute them, so follow this steps:
1. Integrated Security Level Property has to be set to "Authorization" for both, the SD panel and the procedure (or inherit the environment property value where it has to be set to "Authorization").
2. Regarding the Permission Prefix of the SD panel (figure 1) configure a role which includes this permission prefix with the desired Permission Access Type.
Regarding the permission prefix of the procedure (see figure 3), configure a role which includes this permission. See the figure 4.
Figure 4. Permissions of the role
Any user which has this role (figure 5), will have access rights to excute the SD panel as well to execute the action "Subscribe".
Figure 5. Role of the user
1. The permission associated to the Rest webservice is called by default <permission_prefix>_services_execute. See Automatic Permissions generated by GeneXus for details.
2. You can combine the Permission Access Type of the permissions in order to allow or deny the execution of the action.
How to make the management easier
If you want to manage both objects as a whole, that is that if a user is allowed to execute the list he will also be allowed to execute the action, you can manage both permissions at the same time, in the following way:
1. Define a custom permission named "mypermissionsubscrip" for instance, where their children must be the following permissions:
The permission has to be defined for the SD application (the permissions are defined for each Application).
See the figure below:
Figure 6. Create custom permission at application level
2. Add the corresponding permissions (SubscribeNovel_execute and SubscribeToNovels_services_execute) as children of the custom permission "mypermissionsubscrip".
Figure 7. Add children to this permission
3. Add the custom permission "mypermissionsubscrip" to the role.
Figure 8. Add the custom permission to a role, and define the access type of this permission in the role. The children inherit the access type of its father
As the children inherit the access type from their parent, changes in the parent reflect in the children unless the children lose the inheritance. This is very helpfull when all the permissions of the group have the same access type (allow, deny, restricted) so can be managed from their parent. See GAM : Grouping of permissions for details on this topic.
GAM : Grouping of permissions
Full Control Permissions and inheritance
GAM Authorization Scenarios