The following is a guide for the InterformNG2 system administrator on how to configure the system for a high level of security. Security related settings are found in the “Workflow Capabilities” section of the web interface when logged in as the system administrator.

When InterFormNG2 is started for the first time, two users are automatically created with default credentials. Their usernames are “admin” and “default”. As the very first action, the system administrator should log in as “admin” and create a new system admin user with a different username and a strong password. Once the new admin user is created, the default “admin” and “default” users should be deleted.

A number of user roles are available. Users should be assigned the least privileged role that still allows them to perform their assigned tasks.

Only trusted personnel should be granted the system administrator role. 

Users that only need to work with templates and workflows should only be granted the “user” role.

Despite the name, this is a general control for unsafe XML parser functionality.

When this setting is enabled, it is possible to use a number of unsafe functions in XML and XPath parsers and XSL transformers such as reading external resources from a URL and embedding the content into the XML. When InterFormNG2 receives XML from other sources, these features can be exploited for malicious intent. Authenticated users can also exploit this functionality to perform actions that are beyond the limits of their assigned user role.

This is disabled by default. Enabling it introduces very high risk, so it should only be enabled if the unsafe functionality is strictly needed.

Enabling this setting allows workflows and templates to access the local file system on the machine. The application has a built-in blacklist of certain file system locations that workflows and templates are not allowed to access. This prevents access to the most security-critical areas, such as the /profiles folder in the INTERFORMNG2_HOME folder and the folder where the application itself is installed.

The risk of enabling this setting can be mitigated by using the “filesystem allow-list” setting.

On a multi-tenant system where the resources are stored in the file system, enabling this setting means that by default a tenant workflows can access the resources of another tenant through direct file access to the /resources folder. This can be prevented by the “filesystem allow-list” setting.

This setting is enabled by default and introduces medium risk for a single-tenant installation, high risk for a multi-tenant installation. The risk can be reduced to low with the “filesystem allow-list” setting.

The browser available from this setting UI only allows for selection of existing folders under the home folder. To whitelist other folders, write the path manually. For instance “c:/productimages” will allow access to a folder in the root of a Windows server file system.

Enabling this setting enables the workflow component "Execute native O/S command" that runs shell scripts and operating-system commands on the server with the same authority as the user that the InterformNG2 application runs under.

On IBM i, a better alternative to "Execute native O/S command" is the “IBM i Program Call” workflow component.

This is disabled by default. Enabling it introduces very high risk, so it should only be enabled if this functionality is strictly needed.

This setting controls the availability of workflow components that can open outbound network connections. The setting “allow all” allows all such workflow components to be used. Disabling “allow all” gives the option to only enable certain functionality groups of workflow components. It is highly recommended to only enable the groups that are actually needed.

Note that when a group is disabled, the related connection test functionality in settings is also disabled. In the workflow designer, components that are blocked by this setting are still visible but clearly marked as “blocked by security”.

This is set to “allow all” by default and introduces medium risk. The risk can be mitigated by disabling the groups that are not needed.

This setting enables the workflow component "Run a script" that can execute JavaScript code. The JavaScript code runs in a restricted sandbox environment. 

This is disabled by default. Enabling it introduces medium risk and should only be enabled if this functionality is strictly needed.

These settings enable a number of workflow components and XPath expressions that can access a relational database with custom SQL queries defined in workflows and templates.

These settings are all disabled by default. If the application is configured to use an external database, then enabling any of these settings introduces high risk, as it can potentially be used to access the application’s own database tables.

In the default system configuration with embedded databases, it is not possible for workflows to query the embedded databases, so enabling these settings only introduce low risk as long as firewall rules are in place to limit access to other databases on the network.

When this setting is enabled, a system admin can change the password of any user on the system while a tenant admin can change the password of any user on his tenant.

It is recommended to disable this setting and instead configure an e-mail server on system level, so that users can use the password reset functionality to change their own password in case they forget it.