A reverse proxy is usually used to have a single point of access for the front end - or client facing - side of a service. Reverse proxies are typically implemented in a way to increase security, performance and reliability. They also allow having the same service on multiple origin servers - or nodes - without the web client knowing about this architecture and complexity.

Using i-net Clear Reports with a reverse proxy is required in a multi-node environment when using additional servers to scale up the available workforce and provide better performance for parallel access of many users. A reverse proxy can also be used to simply provide a static, client facing access point to the i-net Clear Reports server in a DMZ.

It is recommended to forward the following headers to the original server:

• X-Forwarded-Proto
• X-Forwarded-Host
• X-Forwarded-Port
• X-Forwarded-Context

The HAProxy requires the following options:

# if the application is running using standard https ports
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Proto https if { ssl_fc }
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
http-request set-header X-Forwarded-Context /subcontext
 
# Setting the host is non standard
http-request set-header X-Forwarded-Host %[req.hdr(Host)]

The NGinx requires the following options, which are also documented here:

# if the application is running using standard https ports
proxy_set_header X-Forwarded-Port 443;
proxy_set_header X-Forwarded-Proto https;
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
proxy_set_header X-Forwarded-Context /subcontext;
 
# Setting the host is non standard
proxy_set_header X-Forwarded-Host $remote_addr;

The Apache requires the following options:

# if the application is running using standard https ports
Header set X-Forwarded-Port 443
Header set X-Forwarded-Proto https
 
# if the application is available at a specific subcontext
# e.g. https://mycompany.com/subcontext
Header set X-Forwared-Context /subcontext

The IIS has a process that requires multiple steps to enable forwarding the headers.

1. Install the URL Rewrite IIS extension. This can be downloaded from Microsoft.
2. Install the Application Request Routing (ARR) IIS extension.
3. Enable IIS as proxy.
   • Select the main tree node (Server Name) > Application Request Routing Cache > Server Proxy Settings.
   • Check the Enable Proxy box.
   • Click Apply.
4. Enable forwarding of headers in the menu URL rewrite > Manage Server Variables... > Add and add the following headers:
   • HTTP_X_FORWARDED_PROTO
   • HTTP_X_FORWARDED_HOST
   • HTTP_X_FORWARDED_PORT
   • HTTP_X_FORWARDED_CONTEXT
5. Set up the header fields in the reverse proxy rule as at the following table states

The resulting web.config should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="^api/v1/inet(.*)" />
                    <action type="Rewrite" url="http://localhost:9000{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_FORWARDED_PORT" value="{SERVER_PORT}" />
                        <set name="HTTP_X_FORWARDED_CONTEXT" value="/subcontext" />
                        <set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
                        <set name="HTTP_X_FORWARDED_PROTO" value="https" />
                    </serverVariables>
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

Note: The IIS requires the header fields to be uppercase and combined by underscore instead of a hyphen.

Securing the server with hardened SSL options, and, e.g. HSTS requires additional headers to be set on the proxy - or if none is used - in the Webserver header configuration.

The following headers are derived from the recommendation at https://cipherlist.dev. You can check the settings as seen for browsers using SSL Labs or the SSL Checker. To create hardened SSL options, you may also check the Mozilla SSL config generator.

# Hardening of resource access. Disallows browsers to use other protocols as defined here. Note: only secure protocols are allowed.
# Note: ''designers'' is required only to allow the i-net Designer protocol to open the desktop application
http-response set-header Content-Security-Policy "default-src https: mailto: designers: 'unsafe-inline' 'unsafe-eval'; img-src https: data: blob:; connect-src wss: https:"
 
# SAMEORIGIN allows iframe/cross origin usage. Use DENY to not allow cross origin usage
http-response set-header X-Frame-Options SAMEORIGIN
 
http-response set-header X-Content-Type-Options nosniff
http-response set-header X-XSS-Protection "1; mode=block"
 
http-response set-header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"