Example of proxy setup¶
These images are intended to visualize how clients interact over an external proxy
Calls should be forwarded through an external reverse proxy with filtering capabilities (e.g. Netscaler, f5, BigIP). Caution should always be taken when making sensitive systems accessible from the Internet. Depending on which functionality needs to be accessed from the Internet, only the required requests should be forwarded to the backend servers.
Ifscloud supports two url's systemUrl, which is always required, and a secondarySystemUrl to be used to expose ifscloud on a different proxy with it's own url and certificate. Note that external proxies need to forward the host-header from either secondarySystemUrl or systemUrl for the authentication to be allowed. Note that external proxies need to trust the certificate in the middle tier internal proxy.
Forward filtering and whitelisting of IP addresses are advisable.
This picture illustrates one external proxy (systemUrl parameter) to where both internal and external clients connects and access ifscloud.
This picture illustrates two proxies, one being the internal proxy inside the middle tier ( systemUrl parameter), that all internal clients connects to. This url has the internal domain in its FQDN. For B2B and mobile clients and integrations, another external proxy is configured (secondarySystemUrl parameter). This secondarySystemUrl can have a different external domain in it's FQDN. This external proxy should have whitelisted IP for at least the integration end-points, but preferably also for the b2b and mobile devices if possible.
This picture just shows that the systemUrl (primary/mandatory) also can be fronted by an external proxy, with its own certificate offload, however the internal proxy still need a certificate for the systemUrl. It can be the same as the external proxy (systemUrl), or a self-signed, but it needs to be trusted by the external proxies.