IFS Touch Apps

At IFS user experience is core to everything we do, with a vision for all users to “Love the application”. This means that we design our apps “phone first” and “touch first”. Each app focuses on a very clear task, presents the important rather than all information, is designed to minimize typing, and looks and feels like an app should. Performance and responsiveness of the user interface is critical to the end user experience, as is the ability of the apps to integrate into the eco system and leverage device features and sensors.

In the world of mobile devices, internet connectivity can rarely be guaranteed. If possible Apps are designed to continue to function without disrupting the user experience even in areas of poor or no connectivity. IFS Touch Apps use SQLite or SQLCipher for on-device storage in order to support offline usage.

IFS Touch Apps communicate with IFS Touch Apps Server using JSON over HTTPS.

Securing the device

IFS Touch Apps are most often single-user apps that rely on device security to protect data. Once a device has been unlocked users can view and act on information in the IFS Touch Apps. There are exceptions to this rule; multi-user apps and apps that handle sensitive data. For these apps a password must be entered every time the app is started, but once the app is up and running it can still be accessed by anyone if the device is left unprotected. 

IFS recommend that our customers adhere to best practice routines for protecting their devices. This includes but is not limited to the precautions listed below:

Application Distribution

IFS Touch Apps are distributed through the standard channels for the different platforms; Apple App Store, Google Play and Windows Store. 

Selected IFS Touch Apps are also made available for download through the IFS Touch Apps Server via the LCS delivery system.

User Authentication

IFS Touch Apps use the same authentication mechanism as other IFS Applications clients such as IFS Enterprise Explorer. If IFS Applications has been configured to use an external Open ID Connect Provider then that is what IFS Touch Apps will use. For example if the system has been configured to use Azure AD then that is what IFS Touch Apps will use. If multi factor authentication is required for touch apps then IFS Applications have to be configured to use an external Open ID Connect Provider which supports multi factor authentication.

It is important to note that IFS Touch Apps always uses the DEFAULT application type when authenticating the touch apps users. Please refer here for more information on Application Types

Figure: User Authentication flow chart via IFS Touch Apps Server

User Authorization

Protection of information in the IFS Applications database rests on the same principles as if the IFS Touch Apps were not there. All calls from IFS Touch Apps to IFS Applications are routed through IFS Touch Apps Server which in turn calls IFS Applications using the .NET Access Provider, the same mechanism as used by IFS Enterprise Explorer. This implies that what end users can do from IFS Enterprise Explorer they can also do from an IFS Touch App, if enabled for the system, and what they cannot do from IFS Enterprise Explorer they cannot do from an IFS Touch Apps even if the app is enabled for the system.

For IFS Touch Apps dealing with sensitive data it is possible to make use of additional, app specific grants allowing customers to restrict usage of the IFS Touch Apps to selected personnel. This is in addition to the regular privileges required to access the functionality through IFS Enterprise Explorer.