Reverse proxy / balancer support [Reverse-Proxy / Balancer support]

Operation behind a layer-7 load balancer (HTTP reverse proxy)

In a cloud environment, it may make sense not to connect the server directly to the Internet, but to operate it behind a load balancer or reverse proxy.

These can also take over the SSL termination. This avoids the need to keep a public SSL certificate on the server itself.

However, in order for the AppServer to receive the client IP and the host name used, it must trust the reverse proxy. To do this, the reverse proxy sends custom headers to the AppServer (X-Forwarded-For, X-Forwarded-Proto), in which it communicates the original data. However, the AppServer does not evaluate these headers by default. This would represent a security vulnerability, as otherwise any external caller could pretend to be another machine.

This behavior can be changed via the settings in the Cloud Support tab of the AppServer Service Config. It is recommended that only the IP addresses of the reverse proxy are explicitly enabled.

Additional CORS origins

The same-origin policy (SOP) prohibits reloading from other servers when visiting a website. All data should come from the same source, i.e. the same server. This is a security measure, as JavaScript and CSS can load content from other servers - including harmful content - without the user's knowledge. Such an access attempt is known as a cross-origin request. However, if both website operators are aware of the data exchange and want it, the process can be permitted. The requested server - i.e. the server from which the content is to be reloaded - then allows access via cross-origin resource sharing.

WebSocket tunneling services

WebSocket tunneling for custom protocols

In addition to HTTPS, PARTsolutions also uses other binary protocols (MZCOM or the license protocol), which are proprietary binary protocols. MZCOM is a stream-oriented messaging protocol that implements asynchronous communication between client and AppServer.

The license protocol, in turn, is used to allocate/release licenses. The allocation is linked to a standing connection with the license server.

Both protocols cannot be implemented via HTTPS. However, they can be tunneled via WebSocket (an HTTPS sub-protocol).

This has advantages, but also disadvantages:

WebSocket tunneling is activated in the category PARTsolutions > Application Server > AppServer Service, on the Cloud Support [Cloud-Support] Tabbed page. This functionality is activated by default. If it is not to be used, the corresponding checkboxes should be removed here.

Tabbed page "Cloud support [Cloud-Support]"

Setting options on the client side

On the clients it must be explicitly switched on via the CADENAS_APPSERVER environment variable:

CADENAS_APPSERVER=https://<servername>?ws=1&flm=1

The advantage of switching on via the environment variable is that you can also run mixed configurations:

About the start.env can do this via conditional Blocks also vary accordingly per computer/environment can be configured.

Api access

Force authenticated access [Enforce authenticated access]:

Free prefixes: No API key is required for the registered services. The PDM integrations only use the 3df-config service.

To force authenticated access, proceed as follows:

Please note the following when setting up a PARTsolutions Enterprise installation:

Explicit specification of the host name for the license server

The license system normally has the option of auto-discovery. This means that the license server sends its data (including backup configuration) to the client on request so that the client can automatically address the license server correctly.

This functionality cannot work in a cloud environment in which the public host name does not match the internal name of the license server. To enable this anyway, the (normally automatically determined) host name can be overwritten via config.

To do this, in the License server category, on the Security tabbed page, you can explicitly specify a DNS name under Override server name (for cloud and firewalled servers) [Override server names (for cloud and firewalled servers)] that the server should communicate to the clients during the auto-discovery phase.