Supporto per proxy inverso/bilanciatore [Reverse-Proxy / Balancer support]

Funzionamento dietro un bilanciatore di carico di livello 7 (reverse proxy HTTP)

In un ambiente cloud, potrebbe essere opportuno non collegare il server direttamente a Internet, ma farlo funzionare dietro un bilanciatore di carico o un reverse proxy.

Questi possono anche occuparsi della terminazione SSL. In questo modo si evita la necessità di mantenere un certificato SSL pubblico sul server stesso.

Tuttavia, affinché l' AppServer possa ricevere l'IP del client e il nome host utilizzato, deve fidarsi del reverse proxy. A tal fine, il reverse proxy invia intestazioni personalizzate all' AppServer (X-Forwarded-For, X-Forwarded-Proto), in cui comunica i dati originali. Tuttavia, l' AppServer non valuta queste intestazioni per impostazione predefinita. Questo rappresenterebbe una vulnerabilità per la sicurezza, poiché altrimenti qualsiasi chiamante esterno potrebbe fingere di essere un'altra macchina.

Questo comportamento può essere modificato tramite le impostazioni della scheda Cloud Support di AppServer Service Config. Si consiglia di abilitare esplicitamente solo gli indirizzi IP del reverse proxy.

Origini CORS aggiuntive [Additional CORS origins]

La politica dello stesso origine (SOP) vieta di ricaricare i dati da altri server quando si visita un sito web. Tutti i dati devono provenire dalla stessa fonte, cioè dallo stesso server. Si tratta di una misura di sicurezza, poiché JavaScript e CSS possono caricare contenuti da altri server, compresi quelli dannosi, senza che l'utente se ne accorga. Un simile tentativo di accesso è noto come richiesta di origine incrociata. Tuttavia, se entrambi gli operatori del sito web sono a conoscenza dello scambio di dati e lo desiderano, il processo può essere autorizzato. Il server richiesto, ovvero il server da cui deve essere ricaricato il contenuto, autorizza quindi l'accesso tramite la condivisione delle risorse cross-origin.

Servizi di tunnelling WebSocket [WebSocket tunneling services]

Tunnelling WebSocket per protocolli personalizzati

Oltre a HTTPS, PARTsolutions utilizza anche altri protocolli binari (MZCOM o il protocollo di licenza), che sono protocolli binari proprietari. MZCOM è un protocollo di messaggistica orientato al flusso che implementa la comunicazione asincrona tra client e AppServer.

Il protocollo di licenza, a sua volta, viene utilizzato per assegnare/rilasciare le licenze. L'assegnazione è legata a una connessione permanente con il server delle licenze.

Entrambi i protocolli non possono essere implementati tramite HTTPS. Tuttavia, possono essere collegati in tunnel tramite WebSocket (un sottoprotocollo HTTPS).

Ciò comporta vantaggi, ma anche svantaggi:

Il tunnelling WebSocket è attivato nella categoria PARTsolutions > Application Server > AppServer Service, nella pagina della scheda Cloud Support [Cloud-Support]. Questa funzionalità è attivata per impostazione predefinita. Se non deve essere utilizzata, le caselle di controllo corrispondenti devono essere rimosse.

Figura 4.72. Pagina della scheda "Supporto cloud [Cloud-Support]

Figura 4.73. Impostazione delle opzioni sul lato client

Sui client deve essere attivata esplicitamente tramite la variabile d'ambiente CADENAS_APPSERVER:

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

Il vantaggio dell'attivazione tramite la variabile d'ambiente è che si possono eseguire anche configurazioni miste:

Informazioni sul start.env possibile farlo tramite condizionale I blocchi variano anche di conseguenza in base al computer/ambiente può essere configurato.

Accesso Api [Api access]

Forzare l'accesso autenticato [Enforce authenticated access]:

Figura 4.74. 

Prefissi liberi: non è richiesta alcuna chiave API per i servizi registrati. Le integrazioni PDM utilizzano solo il servizio 3df-config.

Per forzare l'accesso autenticato, procedere come segue:

Quando si configura un'installazione di PARTsolutions Enterprise, tenere presente quanto segue:

Specifica esplicita del nome host per il server delle licenze

Il sistema di licenze ha normalmente l'opzione di rilevamento automatico. Ciò significa che il server delle licenze invia i suoi dati (compresa la configurazione di backup) al client su richiesta, in modo che il client possa indirizzare automaticamente il server delle licenze in modo corretto.

Questa funzionalità non può funzionare in un ambiente cloud in cui il nome host pubblico non corrisponde al nome interno del server delle licenze. Per abilitarla comunque, il nome host (normalmente determinato automaticamente) può essere sovrascritto tramite la configurazione.

A tal fine, nella categoria Licence server [License server], nella pagina della scheda Sicurezza [Security], è possibile specificare esplicitamente un nome DNS in Sovrascrivi nome server (per i server cloud e firewalled) [Override server names (for cloud and firewalled servers)], che il server deve comunicare ai client durante la fase di rilevamento automatico.

Figura 4.75.