Konfiguration allgemein‌

Auf dem inneren Server muss Lobster_data, auf dem DMZ Server der Communication Forward Manager gestartet werden.

Seit Version 5.7.0 des Lobster Integration Servers und speziell in Verbindung mit Version Lobster_data wird die Verwaltung der Kommunikationspartner sowie der zugeordneten Partner-Kanäle und Sicherheitszertifikate vom Authentication Service übernommen.

Der Authentication Service verwaltet Benutzernamen, Passworte, zugeordnete Protokolle und Kommunikationsparameter, sowie Sicherheitszertifikate.

Der Communication Log Service protokolliert Kommunikations-Ereignisse als Log in der Datenbank von Lobster_data, z. B. das Eintreffen einer Datei per AS2 und deren Message ID, etc.

Auf einem DMZ Server wird jeweils eine spezielle Variante beider Dienste verwendet, da die DMZ aus Sicherheitsgründen über keine Datenbank verfügt: Der Message Authentication Service und der Message Communication Log Service, die mit dem jeweiligen Dienst des inneren Servers durch den Austausch von Messages zusammenarbeiten.

Der Message Authentication Service stellt dem DMZ-System prinzipiell die gleichen Funktionen bereit, wie der Authentication Service auf dem inneren Server. Er wird in der Service Factory des DMZ Servers unter dem Namen AuthenticationService registriert. Die Kommunikationsdienste halten ihn deshalb für den Authentication Service. Dieser Name kann aber durch Konfiguration geändert werden. Das gleiche gilt analog für das Dienste-Paar Message Communication Log Service und Communication Log Service.

In der folgenden Abbildung wird die Zusammenarbeit zwischen dem Message Authentication Service im DMZ Server und seinem Authentication Service im inneren Server für einen Empfang per FTP durch den DMZ Server beschrieben. Dies gilt ähnlich auch für die (Message) Communication Log Services.

(1) Der Partner will per FTP über den DMZ Server eine Datei hochladen, die dann von einem Lobster_data-Profil verarbeitet wird. Der FTP Client verbindet sich mit dem FTP Service des DMZ Servers (Port 21). Der FTP Service fordert vom Client die Authentifizierung. Der Client sendet den Username.

(2) Der FTP Service wendet sich an seinen Message Authentication Service, um zu erfragen, ob dem Kommunikationspartner ein FTP-Kanal zugeordnet ist und welche Kommunikationsparameter dazu gespeichert sind. Der Authentication Service des DMZ Servers ist vom Typ com.ebd.hub.services.auth.MessageAuthenticationService, der die Anfragen als synchrone Message an den inneren Server weiterleiten muss, weil nur dieser die geforderte Information zentral verwaltet.

(3) Der Message Authentication Service wendet sich an seinen Message Service, um die Anfrage über die konfigurierte Message Queue als synchrone Message zu versenden. Dabei kann er dem Message Service zusätzliche Informationen, wie das defaultTarget (IP und Port) und den defaultTargetService (Name des inneren Athentication Service) übergeben. Synchrone Messages arbeiten nach dem Anfrage-Antwort-Prinzip, wobei die Antwort über die gleiche Queue zurückgesendet wird. Der Message Authentication Service wartet auf die Antwort.

(4) Der Message Service muss (durch Konfiguration) die Route zum internen Service kennen. Andernfalls übernimmt er die Routing-Information vom defaultTarget, siehe (3). Er übergibt nun eine synchrone Message an die TCP/IP-Schicht, um sie zu der Remote-Schnittstelle des Message Service des inneren Servers zu senden und wartet auf die Antwort.

(5) Die TCP/IP-Schicht des DMZ Servers erzeugt eine TCP-Verbindung zu der IP-Adresse des inneren Servers und der Ziel-Portnummer. Dort hört die Remote-Schnittstelle des Message Service des inneren Servers auf Verbindungswünsche.

(6) Die Firewall muss den Verbindungsaufbau vom DMZ zur Remote-Schnittstelle des inneren Message Service erlauben.

(7) Die Verbindung wird von der Remote-Schnittstelle akzeptiert und die Message empfangen. Die TCP-Verbindung bleibt dabei bestehen, um die Antwort zurück senden zu können.

(8) Die Remote-Schnittstelle übergibt die Message dem inneren Message Service, der sie in die richtige Message Queue einordnet. Dadurch wird sie den Message Consumern, die für diese Queue registriert sind, übergeben.

(9) Der innere Authentication Service ist durch seinen Parameter consumeMessages an dieser Message Queue als Message Consumer registriert worden und empfängt die Message mit der darin enthaltenen Anfrage.

(10) Aus der Anfrage wird durch Zugriff auf die Datenbank eine Antwort formuliert und als Message auf dem umgekehrten Weg wieder zurückgesendet. Nachdem die Antwort den DMZ Server erreicht hat, wird sie über den Message Service dem Message Authentication Service zugestellt, der nun die angeforderten Kommunikations-Parameter des FTP-Kanals dem FTP Service übergibt, damit dieser das Login des Clients akzeptieren oder abweisen kann. Wenn keine Partnerinformationen für den Client Login gefunden werden oder die Anfrage aus anderen Gründen nicht beantwortet werden kann, wird der Login abgewiesen.

(11) Der FTP Service übernimmt nach erfolgreichem Login vom Client die eingelieferte Datei und sendet sie über den Message Service an den inneren Server. Dabei wird eine andere Message Queue verwendet als die vom Authentication Service verwendete.

(12) Wenn in Lobster_data ein passendes Profil auf diese Message Queue registriert ist, wird die Datei diesem Profil zur Verarbeitung zugestellt.

Hinweis: Die Schritte (11) und (12) sind nicht Gegenstand dieses Dokuments.

Im ausgelieferten Standard ist die Installationssoftware bereits fertig vorkonfiguriert, bis auf die verwendete IP-Adresse in den Dateien:

• ./etc/startup.xml beziehungsweise ./etc/startup_dmz.xml

• ./etc/auth.xml beziehungsweise ./etc/auth_dmz.xml

• ./etc/commlog.xml beziehungsweise ./etc/commlog_dmz.xml