IFS TOUCH APPS SERVER ADMINISTRATION GUIDE VERSION

Transcription

1 Mobile & Scheduling Solutions IFS TOUCH APPS SERVER ADMINISTRATION GUIDE VERSION

2 IFS TOUCH APPS SERVER ADMINISTRATION GUIDE 1 ABSTRACT This document describes how to administrate the IFS Touch Apps Server. Contents 1 Abstract Login Customer Portal Customer Information IFS Application Installations Registering the IFS Touch Apps Server with the IFS Cloud Installing Apps Device Approval Upgrading Apps System Configuration App Configuration Mandatory Two Factor Authentication FNDMOB App Configuration System Configuration: App Device Approval System Configuration: App Device Register System Configuration: Authentication Block Authentication Block Configuration Authentication Block in action Configuration parameters Maximum Message size Maximum number of calls Usage Log System Log Category Source Actions Downloads

3 7 Appendix App Device Approval flow Initial client requests Reviewing requests

4 2 LOGIN Open the IFS Touch Apps Server portal on the port specified during the installation (port 8080 by default). You should be presented with a screen that looks something like this: Figure 1: IFS Touch Apps Server - landing page Press Sign in to IFS Touch Apps Server and you will be taken to the sign in screen: 4

5 Figure 2: IFS Touch Apps Server - Sign In page Log in by entering your System ID (as specified during the installation) and the credentials of an IFS Applications user with admin privileges. If you can log in successfully, the installation and configuration has been successfully validated and you can proceed to configure your installation. If you entered an incorrect application server URL during the installation, you can run the installation again and correct it or login as a Local Admin. When you select Local Admin, you log in using the Windows ID and Password for a user that is a member of the Local Administrators group. When logged in you are redirected to the Customer Portal. Note that if you want to manage an FNDMOB app, you should not use the Local Admin mode. See FNDMOB App Configuration. 5

6 3 CUSTOMER PORTAL In the Customer Portal, you can edit your customer information and configure one or more Systems / IFS Applications installations. 3.1 CUSTOMER INFORMATION To edit Customer Information, press Edit, do the desired changes and press Update. 3.2 IFS APPLICATION INSTALLATIONS Each IFS Touch Apps Server installation can handle one or more systems identified by a System ID that is known to the clients. Each system is connected to an IFS Applications Installation. The installer creates and updates the first system in the list. To edit information for a system, press Edit in the list. Figure 3: Service instance details - edit screen For an Apps9 system you get two extra fields for an IFS User and Password. These are only used when using apps based on FNDMOB. See FNDMOB App Configuration. Change desired parameters and press Save. To add a new system, press Add System and fill in information in the same detail window as above. To remove a system, press Remove. 3.3 REGISTERING THE IFS TOUCH APPS SERVER WITH THE IFS CLOUD The IFS Touch Apps Server can be registered with the IFS Cloud. This will allow application DLL s to be synchronized from the IFS Cloud (see Installing Apps below for more information). Registration is optional. To be able to register, the server must be allowed to connect to 6

7 Figure 4: Cloud Connection Status To register the Touch Apps Server with the IFS Cloud, click the Registration link in the Cloud Connection Status section as shown in Figure 4. A system ID is used to uniquely identify the Touch Apps Server with the IFS Cloud. The system ID should have the format <id>.<domain> (e.g. the system id for a Touch Apps Server belonging to IFS might be called tas1.ifsworld.com). You can select any of your existing system ID s for the connection or you can add a new service instance, not connected to an IFS Application installation, dedicated to the IFS Cloud connection. 3.4 INSTALLING APPS Applications are distributed as DLL files. Deployment to the IFS Touch Apps Server is done by copying the DLL to the Apps folder in the Touch Apps Server file structure in IIS. The default location of the deployment directory is c:\inetpub\ifs Touch Apps Server\Apps, where c:\inetpub is the IIS install directory and IFS Touch Apps Server is the name of the IIS Application name as specified when installing the Touch Apps Server. If you are unsure about the location you can view it in the IIS Manager. The physical path to the site can be found under Basic Settings for the IFS Touch Apps Server site. If the Touch Apps Server has been registered with the IFS Cloud, application DLL s can be downloaded and installed through the Customer Portal eliminating the manual file copying step of the app installation. The Download and install App Resources link (see Figure 5) leads to a download page where new and updated DLL s can be downloaded and installed. This page will only list new and updated applications. Already installed software will not show up. Figure 5: App Resource Download Once the applications have been installed they need to be enabled before end users can access them. Please refer to the App Configuration section for information about how this is done. If you are installing an FNDMOB application, additional restrictions apply. See FNDMOB App Configuration. 7

8 3.5 DEVICE APPROVAL This section is only shown if there is at least one system setup to use device approval and there is at least one device awaiting approval. Figure 6: Device Approval Click on the system to get to the App Device Approval page. 3.6 UPGRADING APPS When a new version of an application is released the new DLL should be copied to the Apps folder as described in the Installing Apps section above. If the new DLL has the same name as an existing file, the old file should be overwritten and the new code will be used automatically for any subsequent calls to the app. The normal upgrade scenario is that the new DLL represents a different version of the application and has a new name. When the new DLL is copied to the Apps folder there will be two versions available in the App Configuration page for your systems. To start using the new version it must be enabled for the relevant systems. If upgrading within the same major version (as indicated by the first digit in the version number) the old version will be automatically disabled. Running two releases of an app with the same major revision is not supported. If the new version of the app is a new major version then the old version should remain active until all clients have upgraded to the latest version of the client app. Example: Upgrading from version to Enable version Wait for all clients to upgrade to new client apps 3. Disable version If you are upgrading an FNDMOB application, additional restrictions apply. See FNDMOB App Configuration. 8

9 3.7 SYSTEM CONFIGURATION When pressing Configure for a system ID in the list of IFS Applications installations in the Customer Portal, then you come to the configuration page for that system. Three system level configuration options are available here: 1. Enabling and disabling App Device Approval see App Device Approval 2. Viewing devices already approved or rejected see App Device Register 3. Preventing account lockout due to authentication failures see Authentication Block In addition, this page also lists all the available apps, and some of them provide additional configuration support. Clicking the Configure link for an app takes you to the App Configuration page, detailed below. 3.8 APP CONFIGURATION To change App Configuration for a system, press Configure. Figure 7: App Configuration Select which applications should be enabled for the system. For each application, there can only be one revision enabled within the same major version (e.g and can both be enabled, but and cannot be enabled concurrently). 9

10 3.8.1 MANDATORY TWO FACTOR AUTHENTICATION Some applications support Two Factor Authentication. An additional Mandatory Two Factor Authentication column may be displayed in the above list containing a check box. If none of the applications in the list support Two Factor Authentication, the column is not displayed: this is the case in the screenshot above. The check box is disabled if the application does not support Two Factor Authentication. If the check box is ticked, users must register for Two Factor Authentication to use the application. If the check box is not ticked, Two Factor Authentication is optional FNDMOB APP CONFIGURATION For Apps built on the FNDMOB framework in APPS9 there is some extra configuration functionality. These apps rely on metadata deployed to IFS Applications and require separate granting in IFS Solution Manager. The steps to enable an app like this are: 1. In the portal validate metadata to ensure that the required components are installed in IFS Applications. NOTE: you might see some messages resulting from this operation. INFO messages mean there are no issues in the system. These might appear if the optional components / DB objects are not installed in the IFS Applications instance. ERROR messages mean that mandatory components / DB objects are not installed in the IFS Applications instance. App functionality will not work as expected. 2. In the portal, click the relevant Deploy Meta link. This will deploy metadata about the app to IFS Applications. 3. In IFS Enterprise Explorer (Solution Manager) configure the app and grant access as required. 4. In the portal Enable the app. This will also activate the app in IFS Applications. NOTE: to deploy metadata and enable or disable an FNDMOB app, you must be logged in as a user of the system that you are deploying metadata to, and your user must have the IFS Mobile Admin privilege. You cannot use the Local Admin mode with FNDMOB apps. For more details, please refer to IFS Applications Technical Documentation. 10

11 3.9 SYSTEM CONFIGURATION: APP DEVICE APPROVAL IFS recommend that customers use EMM (Enterprise Mobile Management) or MDM (Mobile Device Management) software to secure mobile devices. The IFS Touch Apps App Device Approval functionality is meant to be used as a compliment to this type of software, where it can be used to ensure that users cannot run IFS Touch Apps from devices that are not under EMM/MDM control. Ticking the Enable App Device Approval check box will show a list of supported apps. Please note that not all IFS Touch Apps currently support App Device Approval, and only supported apps will be listed here. Figure 8: App Device Approval - enabling device approval for individual apps It is possible to switch on App Device Approval before enabling the app for the system. This feature can be used to ensure that access is not possible for unapproved devices. For more details about this functionality, see App Device Approval flow. 11

12 3.10 SYSTEM CONFIGURATION: APP DEVICE REGISTER This page lists the devices connected to the system. By default, Only Pending Approval is set, to show only those devices that have not been approved or rejected yet. Press Approve to allow the user on the device to use the app. Press Reject to prevent the user on the device to use the app. Figure 9: App Device Register - Only Pending Approvals To reject a device that has previously been approved: Uncheck Only Pending Approvals to show all devices. Press Reject for the desired device. Figure 10: App Device Register - all 12

13 3.11 SYSTEM CONFIGURATION: AUTHENTICATION BLOCK AUTHENTICATION BLOCK CONFIGURATION Touch Apps Server and later supports the Authentication Block functionality, which introduced a configurable limit of authentication failures per user and system. This works by tracking each authentication failure for a configurable duration, and then blocking authentication attempts if a threshold number of authentication failures are currently being tracked. This prevents authentication failures from locking the user at either the Database level or at the corporate network level in Single Sign-On (SSO) environments. Authentication Block is Disabled by default, and can be enabled and configured on each System ID as required. Figure 11: Authentication Block in Disabled state Tick the Checkbox to Enable the Authentication Block functionality. This will then make the two input boxes editable with the default values. Modify the values if required, and then press the Update button to save and apply the changes. Untick again and press the Update button to disable Authentication Block. Note: Authentication Block settings are not automatically saved and applied, and must be applied with the Update button Figure 12: Enable and configure Authentication Block 13

14 The default value for Threshold and Duration are explained below. Configuration Setting Definition Default value Authentication Block Threshold Authentication Block Duration The number of authentication failures that will trigger blocking of further authentication attempts. Each authentication failure will be tracked for this time duration. Authentication attempts will be blocked if the currently tracked authentication failure count matches the Threshold. 2 authentication failures 300 seconds (5 minutes) AUTHENTICATION BLOCK IN ACTION Let s assume on a certain system, you enabled Authentication Block with the default values of blocking on 2 authentication failures within a tracking duration of 5 minutes. You can now try to authenticate on any app running on that Touch Apps Server against that System ID. On the first failed authentication attempt, let s say at 09:02, you will see the standard error message, and the TAS will record this authentication failure for the System ID + User ID combination along with the timestamp. On the second failed authentication attempt, let s say at 09:04, you will again see the standard error message. The TAS will record this failure as well along with the timestamp. Refreshing the TAS page will list the User ID s currently blocked, and your user will also be listed there since two failures are being tracked. This authentication block applies from 09:04 until tracking of the first failed attempt expires (i.e.: 09:02 expires at 09:07, a block of 3 minutes). Let s say you make another failed login attempt at 09:08. The TAS will not block this attempt, since only one failure (from 09:04) is currently being tracked, but will note the failure. The threshold exceeds again, so Authentication Block applies once again and will last until 09:09 (a block of 1 minute) until tracking of the 09:04 failure stops. 14

15 Figure 13: List of Blocked Users The user will be unblocked when The time since the last recorded authentication failure is greater than the Duration parameter, Or you press the Unblock link against the user you want to unblock (in which case only the chosen user will be unblocked), Or you press the Unblock All link (in which case all currently blocked users are unblocked). Any authentication attempts, whether valid or invalid, while the user is blocked, will result in the Authentication Blocked message. This means that the database will not see the invalid authentication attempt, thus reducing the likelihood of the Oracle or SSO user being locked. Figure 14: Authentication Blocked message Note: Unblocking a blocked user clears the TAS s list of failed authentication attempts, but does not clear the number of failed authentication attempts tracked for that Oracle / SSO user. 15

16 3.12 CONFIGURATION PARAMETERS The file web.config (default location c:\inetpub\ifs Touch Apps Server\web.config) contains parameters that can be adjusted to fit the customer installation MAXIMUM MESSAGE SIZE The default settings for inbound messages are set to 8MB with individual values restricted to 4MB. In a system where the end users might send larger files (e.g. high-resolution photos or videos) these values should be adjusted accordingly. The settings in question are maxreceivedmessagesize and maxstringcontentlength, both found in the <system.servicemodel><bindings> section of the configuration file. The values are given in number of bytes. The maximum size for strings in outbound messages is controlled by MaxJsonLength in <appsettings>. The default value is 4MB. In some installations, this might have to be increased. This setting does not affect binary downloads such as document attachments MAXIMUM NUMBER OF CALLS The default settings allow for 500 concurrent calls to be processed by the Touch Apps Server. This setting does not correlate directly with the maximum number of users and 500 concurrent calls would normally be sufficient even in very large installations. The more concurrent calls an installation allows the higher the potential load on the database. In large installations with 1000 s of users initializing their devices concurrently this setting might have to be changed to achieve maximum throughput. However, it s vital in these situations to monitor the load on the database since this will typically be the bottle neck. Over loading the database might also result in lowered throughput so sometimes it s better to throttle end user requests in the Touch Apps Server. The relevant parameters are maxconcurrentcalls, maxconcurrentsessions and maxconcurrentinstances, found in the <system.servicemodel><behaviors><servicebehaviors> section of the configuration file. These parameters control the maximum number of incoming requests that can be processed by the Touch Apps Server. There is also maxconnection under <system.net><connectionmanagement>. This setting controls the maximum number of outgoing connections (i.e. calls to the IFS Applications installation) and can also be used as an optimization setting. The typical scenario would be to set maxconnection, maxconcurrentcalls and maxconcurrentsessions to the same value, with maxconcurrentinstances set to double this value. Sometimes though, a system might perform better with a lower maxconnection setting. If the load on the IFS Applications database is too high, lowering maxconnection might not only reduce the load on the database, it might increase throughput. 16

17 4 USAGE LOG Figure 15: Usage Log page The Usage Log allows users to monitor application usage. The user will enter the desired From and to dates and press View or Export to Excel. The summary option will list app usage by customer (as shown in the screenshot above). The export to excel option will export an excel file with more detailed usage information. 17

18 5 SYSTEM LOG Figure 16: System Log page Here you can view entries from the System Log. You can use criteria to the limit the result set. The functionality is shared between the Cloud and TAS so some criteria are valid for both and some only for one of them. 5.1 CATEGORY App Management Entries about uploading and publishing of app resources. Configuration Update Entries about changes of Admin Portal data. Failed Authentication Entries for users that couldn t authenticate, can be wrong password, backend not reachable etc. Failed Authorization Entries for users that could authenticate but lack a needed privilege. E.g. Lacking privilege: "System Privilege: ADMINISTRATOR". 5.2 SOURCE Client Entries originating from clients. Customer Portal Entries originating from the Customer Portal 5.3 ACTIONS View Shows data in the page Export to Excel Exports the data directly. 18

19 6 DOWNLOADS Apart from the store distribution method, Mobile app clients can be distributed using the downloads page in Touch Apps Server. Once you place the installation file in the following directory, c:\inetpub\ifs Touch Apps Server\{{SYSTEM ID}}\ it will be shown in the downloads page. (Figure 17) Supported File types. Android IOS Windows.apk.ipa.exe Figure 17: Downloads Page 19

20 7 APPENDIX 7.1 APP DEVICE APPROVAL FLOW Once App Device Approval has been enabled for an app, as described in System Configuration: App Device Approval, the functionality is active and will disallow app usage on a device until an administrator has reviewed and approved the request. This section will describe how this appears to end users and administrators both INITIAL CLIENT REQUESTS The first step is for a user to install and try to run the app on their device. The user will then see a message like that shown in Figure 18. Figure 18: App Device Approval - initial client message Subsequent attempts to use the app before usage has been approved will result in a similar error message stating Usage of this app is pending approval by your system administrator. 20

21 7.1.2 REVIEWING REQUESTS To view pending device app usage approval requests the administrator must log in to the Customer Portal, where a new section Device Approval will show up at the top of the page (see Figure 19). Figure 19: Device Approval - requests pending Clicking the System ID will take the administrator to a detail page listing all approval requests, both historical and active. Historical (approved/rejected) request are hidden by default, but can be shown by unchecking the Only Pending Approvals checkbox. Figure 20: Device Approval - detail page Usage requests can be approved or rejected by clicking the corresponding Action link in the rightmost column of the table. Once the request has been approved the user can start using the app. If app usage is rejected, any future attempts to use the app on the rejected device will result in an error message: Usage of this app is not allowed on this device. 21

22 To reject a device that has previously been approved, clear the Only Pending Approvals checkbox to show all devices and press Reject for the desired device. Figure 21: Device Approval - reject previously approved request 22