Für den Einsatz des AppServer in Cloud-Umgebungen gibt es verschiedene Möglichkeiten:
Reverse-Proxy / Balancer support
Betrieb hinter einem Layer-7 Loadbalancer (HTTP-Reverse-Proxy)
In einer Cloud-Umbegung kann es sinnvoll sein, den Server nicht direkt mit dem Internet zu verbinden, sondern ihn hinter einem Loadbalancer bzw. einem Reverse-Proxy zu betreiben.
Diese können auch die SSL-Terminierung übernehmen. Damit vermeidet man das Vorhalten eines öffentlichen SSL-Zertifikats auf dem Server selbst.
Damit der AppServer dann aber die Client-IP und auch den verwendeten Hostnamen übermittelt bekommt, muss er dem Reverse-Proxy vertrauen. Dazu schickt der Reverse-Proxy Custom-Header an den AppServer (X-Forwarded-For, X-Forwarded-Proto), in denen er die Originaldaten mitteilt. Standardmäßig wertet der AppServer diese Header aber nicht aus. Dies würde eine Sicherheitslücke darstellen, da sonst jeder externe Aufrufer sich für eine andere Maschine ausgeben könnte.
Über die Einstellungen im Cloud-Support-Tab der AppServer-Service Config kann man dieses Verhalten umstellen. Es wird empfohlen, nur die IP-Addressen des Reverse-Proxies explizit freizuschalten.
Zusätzliche CORS-Origins [Additional CORS origins]
Die Same-Origin-Policy (SOP) verbietet beim Besuch einer Website das Nachladen von anderen Servern. Alle Daten sollen von der gleichen Quelle kommen, also dem gleichen Server entspringen. Das ist eine Sicherheitsmaßnahme, denn JavaScript und CSS könne ohne das Wissen der Nutzer Inhalte von anderen Servern laden – auch schädliche Inhalte. Ein solcher Zugriffsversuch wird als Cross-Origin-Request bezeichnet. Ist aber beiden Websitebetreibern der Datenaustausch bekannt und von diesen auch gewünscht, kann man den Vorgang erlauben. Der angefragte Server – also der, von dem Inhalte nachgeladen werden sollen – erlaubt den Zugriff dann per Cross-Origin Resource Sharing.
Default: Ist nichts angegeben, ist der Fully Qualified Domain Name des Servers erlaubt.
Liste zusätzlicher Origins (Komma-separiert) [List of additional origins (comma-separated)]: Im Eingabefeld lassen sich zusätzliche Origins angeben.
Erlaube alle Origins (Unsicher) [Allow all Origins (Unsecure)]: Alternativ kann das Auswahlkästchen aktiviert werden, um alle Quellen zuzulassen.
WebSocket-Tunneling Dienste [WebSocket tunneling services]
WebSocket-Tunneling für Custom-Protokolle
PARTsolutions verwendet zusätztlich zu HTTPS noch andere Binärprotokolle (MZCOM oder das Lizenz-Protokoll), die proprietäre binäre Protokolle darstellen. MZCOM stellt hier ein stream-orientiertes Messaging-Protokoll dar, mit dem asynchrone Kommunikation zwischen Client und AppServer implementiert wird.
Das Lizenz-Protokoll wiederum wird verwendet, um Lizenzen zu belegen/freizugeben. Die Belegung ist dabei an eine stehende Verbindung mit dem Lizenzserver gebunden.
Beide Protokolle sind nicht via HTTPS umsetzbar. Sie können aber über WebSocket (ein HTTPS-Subprotokoll) getunnelt werden.
Dies hat Vorteile, aber auch Nachteile:
Der Verbindungsaufbau ist langsamer als mit den nativen Protokollen.
Der worker-Threadpool des Webservers wird mit diesen zusätzlichen stehenden Verbindungen belastet.
Im Falle des Lizenzprotokoll Tunnelings wird doppelt verschlüsselt. (SSL zum Server, und dann noch mal im Protokoll selbst auch).
Das Lizenz-Protokoll-Tunneling erlaubt nur Single-Lizenzserver Umgebungen (keine Master-Backup oder Triaden-Konfiguration möglich).
Die Aktivierung des WebSocket Tunnelings erfolgt in Kategorie PARTsolutions > Application Server > AppServer Service, auf der Registerseite Cloud-Support. Diese Funktionalität ist per Default eingeschaltet. Soll sie nicht genutzt werden, so sollte man die entsprechenden Haken hier entfernen.
Auf den Clients muss sie über die CADENAS_APPSERVER Umgebungsvariable explizit eingeschaltet werden:
CADENAS_APPSERVER=https://<servername>?ws=1&flm=1
Der Vorteil des Einschaltens über die Umgebungsvariable besteht darin, dass man auch gemischte Konfigurationen fahren kann:
Über die
start.envkann dies über bedingte Blöcke auch pro Rechner/Umgebung entsprechend unterschiedlich konfiguriert werden.Erzwinge authentifizierten Zugriff [Enforce authenticated access]:
Freie Präfixe: Für die eingetragenen Services wird kein API-Key benötigt. Die PDM-Integrationen nutzen nur den 3df-config Service.
Um einen authentifizierten Zugriff zu erzwingen, gehen Sie folgendermaßen vor:
Legen Sie mittels einen Api-Key an.
Es können auch mehrere Api-Keys angelegt werden: Für interne Installationen, für externe Installationen (externe Zulieferer). Mit können bestimmte Api-Keys jederzeit wieder entfernt werden, ohne dass die übrigen Installationen davon berührt werden.
Tragen Sie in der Spalte Kommentar [Comment] eine prägnante Beschreibung ein.
Führen Sie auf dem gewünschten Api-Key einen Doppelklick aus.→
→ Das Dialogfenster Zeige Appserver-Url [Show appserver url] wird geöffnet.
Kopieren Sie die Url und passen Sie den Servernamen auf Ihren Fall an.
Beachten Sie beim Aufsetzen einer PARTsolutions Enterprise Installation Folgendes:
Explizites Vorgeben des Hostnamens für den Lizenzserver
Das Lizenzsystem verfügt normalerweise über die Möglichkeit der Auto-Discovery. Das bedeutet, dass der Lizenzserver seine Daten (inklusive Backup-Konfiguration) auf Anfrage an den Client schickt, so dass dieser die Lizenzserver automatisch korrekt ansprechen kann.
Diese Funktionalität kann in einer Cloud-Umgebung nicht funktionieren, in der der öffentliche Hostname nicht mit dem internen Namen des Lizenzservers übereinstimmt. Um dies trotzdem zu ermöglichen, kann der (normalerweise automatisch ermittelte) Hostname per config überschrieben werden.
Dazu kann in der Kategorie Lizenzserver [License server], auf der Registerseite Sicherheit [Security], explizit unter Überschreibe Servernamen (für Cloud- und Firewalled Server) [Override server names (for cloud and firewalled servers)] ein DNS-Name angegeben werden, den der Server den Clients während der Auto-Discovery Phase mitteilen soll.
