Running Behind a Reverse Proxy
In some cases, it is advantageous to use a reverse proxy as an intermediary between the Model Manager server and its users. Use cases of a reverse proxy include:
•
Providing many web services with the same hostname — for example, serving the Model Manager server at example.com/modelmanagerserver and a webmail server at example.com/webmail.
•
Offloading TLS encryption onto the reverse proxy, either for using hardware-accelerated encryption or to simply avoid configuring encryption for each web service separately.
•
Firewall features that protect the web service from attacks.
•
Integration with single sign-on systems for authentication — see Proxy Authentication.
To support serving the Model Manager server at the path /modelmanagerserver, as in the preceding example, the reverse proxy must be configured to pass any regular HTTP requests to, for example, example.com/modelmanagerserver/foo on to the Model Manager server as modelmanagerserver.com:8181/foo. Additionally, the reverse proxy should be configured to rewrite the cookie path /api set by the Model Manager server to /modelmanagerserver/api.
Any reverse proxy that supports HTTP can be used with the Model Manager server. Two common reverse proxies are Apache mod_proxy and NGINX®. See the documentation of the reverse proxy software for how to set it up to forward requests.
You can use the ProxyPassReverseCookiePath directive in Apache mod_proxy and the proxy_cookie_path directive in NGINX® to rewrite the cookie path.
TLS Encryption
By configuring the reverse proxy to serve HTTPS, the integrity and confidentiality of the communication between the client and the reverse proxy is protected by the TLS protocol. This is the recommended way to host the Model Manager server on any network where cleartext traffic could be intercepted.