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 INETAPP 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 INETAPP 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.
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
Server variable name | Value | Replace |
---|---|---|
HTTP_X_FORWARDED_PORT | {SERVER_PORT} | True |
HTTP_X_FORWARDED_CONTEXT | /subcontext | True |
HTTP_X_FORWARDED_HOST | {HTTP_HOST} | True |
HTTP_X_FORWARDED_PROTO | https (only if HTTPS is enabled) | True |
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"