Because of the Online Native Mobile applications architecture, some security recommendations must be taken into account when developing this type of applications.
By security we mean Authentication and Authorization features, and in this document we will focus on application security at the Authorization level.
Just as it is done in web applications, in which security controls are performed both in the client and the web server, the same happens in Smart Device applications where filters and controls at the interface level must also be considered and reflected in the REST Web Services that execute the business logic of applications.
Transactions to which the WW pattern for SD are applied, are automatically set as Business Component (Business Component property = TRUE) and exposed as a Rest service (Expose as web service = TRUE, web service protocol = Rest Protocol).
By default, the Rest service exposes the Display, Insert, Update, Delete methods of the Business Component.
If the application being developed is read-only (that is to say, from the device the data will not be updated via the BC), the update services will _not_ be used by the application. So, an alternative is to inhibit access to the services in INS, UPD, DELETE mode by disabling the “insert”, “update”, “delete” property of the BC within the web service usage section.
If the “view” property is disabled (at the web service usage level of the BC) it will not be possible to update or delete data from the BC either. The reason is that disabling the view implies that the BC cannot be invoked with the GET method, and to perform PUT HTTP (update) or DELETE HTTP the GET method must be performed first. For more information, read REST Web Services.
Applying the WW pattern for SD also generates data providers which are also exposed as read-only REST services that can be accessed with a GET http. To protect these services from being executed by unauthorized users, and ensure the confidentiality of your data, the GAM must be enabled.
Besides, you need to take into consideration some topics related to the fact that these dataproviders are exposed as web services if you need to stablish security at data level. See the following items for details.
The security solution to implement security features (Authentication and Authorization) for Smart Device applications is integrated into GeneXus: GeneXus Access Manager.
When GAM is enabled, only identified users can access the services. Users will have access as long as they have the application's Client Secret (see HowTo: Develop Secure REST Web Services in GeneXus).
When the GAM is used, all REST services exposed by the application (services associated with Business Components, Procedures and Data Providers exposed as REST services) will be accessed only by authenticated and/or authorized users.
In particular, it should be taken into account that procedures called from SD object events are automatically converted to REST services that can be accessed through an http POST, and this is transparent for the programmer. The only way to make sure that they are accessed by authorized users is to indicate that Authentication (Authorization) is required to execute the service. The same happens with dataproviders called from SD object events (they are automatically converted to REST services that can be accessed through an http GET).
In summary, in all these cases GAM must be used to ensure the integrity of the SD application data.
If GAM is not enabled, the REST services that solve the application business layer are exposed in such a way that they can be accessed via HTTP by any user, from any HTTP client other than the SD application itself.
Because GAM still doesn’t support managing permissions at the data level (that is to say, with GAM you can’t set permissions for a user over certain data while restricting access to other information), here is a way to program our SD application services in a secure way that takes this into account.
If the application is accessed by users from different companies with privileges in some table records (those of their company), or if the applications allow managing personal details (that is to say, users can only view and change their own data but not other users' information), we must take some considerations into account when programming those objects executed as services.
We must remember that:
- Filters and security controls which are programmed in the client now must be programmed in the services.
- The security code that in web applications is in the Start event of transactions must be changed to rules in BC because they don’t execute start Event when exposed as REST.
It is assumed that the application has GAM enabled.
The SD WW is applied to the "account movements" transaction. Movements can only be viewed, entered, updated by the clients associated with those movements.
That is to say, the movements transaction is as follows:
When the SD WW is applied to the transaction, it is automatically set as a BC (Business Component property = TRUE) and exposed as a Rest service (Expose as web service = TRUE, web service protocol = Rest Protocol).
At the user interface level, in the grid where movements are displayed, there is a condition associated with a data selector that filters by the logged in user. That is to say, the logged in user only sees his/her movements (see HowTo: Filtering Data by User Using the GAM API)
This control made at the interface level must be made in the exposed REST service.
In order to ensure that a user only enters movements associated with his user account, the following rule is programmed in the BC:
ClientCod = GAMUser.GetId() if insert;
To ensure that in update or delete mode users only update or delete their own movements, the following is programmed:
Error("YOU’RE NOT AUTHORIZED TO PERFORM THIS ACTION") if ClientCod <> GAMUser.GetId() and (insert or update or delete);
For viewing data, it must be taken into account that users must be allowed to see their own movements, and not those of other users.
Error("YOU’RE NOT AUTHORIZED TO PERFORM THIS ACTION") if ClientCod <> GAMUser.GetId() and display;
Because the display mode is always executed before update and delete, the last two rules are combined in one:
Error("YOU’RE NOT AUTHORIZED TO PERFORM THIS ACTION") if ClientCod <> GAMUser.GetId() and (insert or display);
The above is valid as from Upgrade 2 of GeneXus Evolution 2.
When using a previous version, the following must be programmed in Business Components exposed as REST to ensure data integrity.
&isAuthorized = IsAuthorized.Udp(ClientCod) if &Mode = 'DSP';
&isAuthorized = TRUE;
//Close all transaction fields
if not &isAuthorized;
.......//likewise, close the transaction attributes
Where the procedure is IsAuthorized is:
if &clientCod= GAMUser.GetId()
&Authorized = TRUE
&Authorized = FALSE
Note that the case in which a user can’t add movements is solved with GAM permissions.
In case of procedures and dataproviders that are exposed as Rest web services, you have to add the condition in the code.
where ClientCod = GAMUser.GetId()
where <other conditions>
Note that the filter by ClientCod is done using the GAM session, the ClientCod is not passed as parameter.
When the SD WW is applied to the transaction, a set of dataproviders exposed as Rest web services are generated. For example, for a transacion named Invoice at least the following are generated: WorkWithDevicesInvoice_List_Grid, WorkWithDevicesInvoice_Detail, WorkWithDevicesInvoice_Section_General.
The way to control that these dataproviders executed as web services do no allow users to access data of other users is to add the corresponding condition (ClientCod = GAMUser.GetId()) at _all_ nodes of the WorkWithDevicesInvoice object. That is, you need to edit the conditions tab of all the nodes of the WW object and declare the corresponding condition there.
Going into production: checklist for Applications using GAM