Security

This chapter describes how to run an Axon.ivy Engine in a secure way. This is important when providing an ivy engine in a secure intranet environment and especially when making an engine accessible over the internet. Some parts might be done by the IT Operation provider:

Run the Axon.ivy Engine behind a fully patched front-end server (like IIS, nginx) with restricted accessibility (paths, ports, users, etc.).
Only allow access to the URLs of your application / block access to system URLs.
Disable direct access to the Axon.ivy Engine.
Run the Axon.ivy Engine with a dedicated system user and database users with limited access rights.
Run the latest Axon.ivy Engine major version with all updates marked as security relevant.
Only serve users over HTTPS (configured on the front-end server (IIS/nginx).
Document and automate the server setup.
Ensure that the provider performs daily backups (database, relevant engine folders).

Front-end Server

A front-end server is a server over which a user accesses the Axon.ivy Engine. There are roughly three types of front-end servers:

Web servers (e.g. Microsoft IIS, nginx, Apache HTTP Server)
Web Application Firewalls (WAF)
Custom cloud provider reverse proxies (often nginx based)

Port Configuration

Aim: Only allow communication with the Axon.ivy Engine through the front-end server. Don’t allow direct access to the Axon.ivy Engine ports (e.g. 8080, 8443, 8009) from the outside. Requests should always be perfomed through a front-end server (e.g. IIS). It’s best to open up only the ports in the firewall that are really needed (most of the times (HTTP (80) and/or HTTPS (443). It’s best to automate these port tests for continuous security.
Test: Check if you can reach the ivy Engine over port 8080 (the port defined in the config).
Expected outcome: The Engine should not be reachable.

Tip

When using Ubuntu Linux as a server make sure to enable and configure the firewall (ufw) as it’s not enabled by default.

Additional Security Headers

Following additional security headers are recommended.

Header	Description
Strict-Transport-Security	Set this header if the Engine should only be accessed over HTTPS (strongly recommended). For more information, see: Strict-Transport-Security. Can be adjusted on the embedded Tomcat with the pre-configured Http Header Security Filter in the web.xml
Content-Security-Policy	Set this header if you want to reduce the risk of having an exploitable Cross-site scripting (XSS) vulnerability. With a Content-Security-Policy you can define from which locations external resources can be loaded and if scripts embedded in HTML can be executed. For more information, see: Content Security Policy (CSP). Check https://answers.axonivy.com/questions/2982 to see a CSP example with the embedded Tomcat.
Referrer-Policy	Set this header if you want to control how or if the referrer is disclosed to other sites. For more information, see: Referrer-Policy

Path Configuration

Aim

Only allow paths from the front-end server to the Axon.ivy Engine that are required by your ivy projects to work correctly.

Test

Check if you can reach http(s)://<front-end-server>/ivy/error (and all other blocked URLs). Also check if you can access your process that should be available to end users. Note that the ivy servlet is not necessarily running under /ivy/. It is best to automate these tests for continuous security.

Expected Outcome

Forbidden paths should not be reachable (HTTP Status: 4xx). The process should be reachable for end users.

Example for a JSF-based Application

Filter following URL parts:

URL Part	Used for
/ivy/error	Displaying and administering Errors
/ivy/pagearchive	Page Archive
/ivy/api/	Workflow API, REST APIs
/ivy/wf/	Server Workflow UI
/ivy/info	Process overview page
/ivy/faces/view/system	Engine Cockpit (Setup Wizard)

Block URLs in IIS

Unfortunately, IIS does not seem to have support for white listing URLs, so we have to use a black list approach using request filtering, in which we block URL segments.

Warning

When using the request filter on IIS the URL parts are generally not allowed. A filter /ivy/error means that /ivy/bla/ivy/error/test is also not allowed (because it is a part of the URL).

After changing the configuration restart IIS and check that the URLs are not accessible anymore.

Block URLs in nginx

In the nginx server configuration, URLs can be blocked like this (repeat for the other URLs).

location /ivy/pro/System {
    deny all;
    return 403;
}

After changing the configuration restart nginx and check that the URLs are not accessible anymore.

Block URLs on the ivy Engine / Tomcat

Alternatively, URLs can also be blocked directly on the ivy Engine which utilizes and underlying Apache Tomcat for serving HTTP requests. Open the web.xml file in [engineDir]/webapps/ivy/WEB-INF/ in a text editor and add the following configuration inside the <web-app> tag (!) to block system processes:

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>
   ...
    <security-constraint>
      <display-name>Restrict access to System Processes</display-name>
        <web-resource-collection>
          <web-resource-name>System Processes</web-resource-name>
          <url-pattern>/pro/System/*</url-pattern>
        </web-resource-collection>
      <auth-constraint />
    </security-constraint>
   ...
</web-app>

After changing the configuration restart the ivy Engine and check that the URLs are not accessible anymore.

Tip

If the URLs are still accessible after blocking them in the web.xml make sure that you didn’t include the servlet path (/ivy) in the URL pattern.

HTTPS

It is strongly recommended to protect the connection to the server with HTTPS, especially when transferring sensitive data (like passwords). HTTPS connections should be configured on the front-end server. Only current TLS/SSL settings (e.g. no SSLv3 or TLSv1.0) and only up-to-date systems (e.g. no OpenSSL with Heartbleed) should be used. Consult the manual of your front-end server for a secure HTTPS setup.

Remarks

Current browsers mark login forms with password fields over HTTP as insecure.
Enable the secure flag in the web.xml on session cookies when using HTTPS.
Enable HTTP Strict Transport Security (HSTS) (with the httpHeaderSecurity filter in the web.xml or in the configuration of the front-end server).

Axon.ivy Engine

Disable not required features

If certain features of the Engine are not required by the deployed projects, those features should be disabled.

Optional features

The following features can be disabled if they are not used by the deployed projects:

# ivy.webserver.yaml with all optional features disabled
REST.Servlet:     
  # If none of the deployed projects provide REST APIs it is also possible to disable the whole REST servlet 
  Enabled: false
     
  # REST resources for the mobile app under '/api/{application}/workflow'
  # If the Mobile Workflow REST API is not used on your engine (e.g. by the Axon.ivy Mobile App) you can disable it
  MobileWorkflow.API: false

  # REST resource for remote deployment under '/api/system/apps/{application}' 
  # If remote deployment is not used on your engine you can disable it
  # The REST Deployment is used from the deployment feature of the Engine Cockpit
  Deployment: false

# If the Mobile Offline Dialogs are not used on your engine (most of the time) you can disable them
OfflineDialog.Enabled: false

Security Features

The following features impact the security and have a good default (depending on what’s better for security) and should not be changed. These feature flags are set in the ivy.yaml and ivy.webserver.yaml.

Errors.ShowDetailsToEndUsers should always be set to false, so that no exception details are shown to end users.
REST.Servlet.CSRF.Protection should always be set to true, so that the REST APIs require a Cross-Site Request Forgery (CSRF) token by default. See Secure REST APIs for more information about secure REST API configuration.
Session.RenewIdOnLogin should always be set to true, so that the session id is renewed after Login.

By default, all cookies (inclusive the session cookie JSESSIONID) have set the same-site cookie header to value lax. You can disable or harden XSS cookie restrictions in context.xml.

Only grant ivy permissions where required

Only grant ivy permissions where the users or roles require them. Especially don’t grant all permissions to everybody. Favor role-based permissions over user-based ones.

Security issues in the Axon.ivy Engine

If a security issue was found in the Axon.ivy Engine or Designer it is visible in the release notes, annotated with an exclamation mark (!):

! Critical: We strongly recommend to install this hotfix because it fixes a critical security issue!
* Recommended: We recommend to install this hotfix because it fixes a stability issue.
+ Suggested/Optional: We only recommend to install this hotfix if you are running into the described issue.

Update the engine if your engine version is affected by an issue and it cannot be mitigated by a workaround.