Configuration in General
Lobster_data has to be launched on the inner server and the Communication Forward Manager on the DMZ server.
Since version 5.7.0 of the Lobster Integration Server and especially in combination with version Lobster_data.3.x communication partners, assigned partner channels, and certificates are administered by the Authentication Service.
The Authentication Service administers user names, passwords, assigned protocols and communication parameters as well as certificates.
The Communication Log Service logs communication events in the database of Lobster_data, for example, the arrival of a file via AS2 and its message ID, etc.
A special variant of both services is used on a DMZ server, as the DMZ is not equipped with a database for safety reasons: The Message Authentication Service and the Message Communication Log Service that exchange messages with the respective service of the inner server.
The Message Authentication Service in principle provides the same functionality to the DMZ server as the Authentication Service on the inner server does. It is registered in the Service Factory of the DMZ servers using the name AuthenticationService. The communication services, therefore, consider it being the Authentication Service. This name can be changed in the configuration. The same holds true for the pair of services Message Communication Log Service and Communication Log Service.
In the following figure, the cooperation of the Message Authentication Service on the DMZ server and its Authentication Service on the inner server is described for receiving data via FTP using the DMZ server. (Message) Communication Log Services work in a similar fashion.
(1) The partner wants to upload a file using FTP via the DMZ server, which then will be processed by a Lobster_data profile. The FTP client connects to the FTP service of the DMZ server (port 21). The FTP service demands authentication from the client. The client sends the user name.
(2) The FTP service turns to its Message Authentication Service to enquire if an FTP channel is assigned to the partner and if so which communication parameters are stored for the channel. The Authentication Service of the DMZ server is of type com.ebd.hub.services.auth.MessageAuthenticationService, which needs to redirect the request as a synchronous message to the inner server because only that administers the required information.
(3) The Message Authentication Service contacts its Message Service to send the request via the configured Message Queue as a synchronous message. In the process, other information like the defaultTarget (IP and port) and the defaultTargetService (name of the inner authentication service) can be handed over. Synchronous messages work using the request-response principle. The response is sent via the same queue. The Message Authentication Service is waiting for a response.
(4) The Message Service must (through configuration) know the route to the internal service. Failing this, it inherits the routing information from the defaultTarget, see (3). It hands over a synchronous message to the TCP/IP layer in order to send it to the remote interface of the Message Service of the inner server and waits for a reply.
(5) The TCP/IP layer of the DMZ server establishes a TCP connection to the IP address of the inner server using the destination port number. There, the remote interface of the Message Service of the inner server waits for connection requests.
(6) The firewall needs to grant connection from the DMZ to the remote interface of the inner Message Service.
(7) The connection is accepted by the remote interface and the message is being received. The TCP connection is kept alive to send back the reply.
(8) The remote interface hands the message over to the inner Message Service, which assigns it to the correct Message Queue. Thereby, it is handed over to the Message Consumers assigned to this queue.
(9) The inner Authentication Service has been registered to this Message Queue as a Message Consumer through the parameter ’consumeMessages’ and receives the message with the contained request.
(10) By accessing a database, a response is generated from the request and sent back as a message on the reverse path. After the reply has reached the DMZ server it is delivered via the Message Service to the Message Authentication Service, which now can hand the requested communication parameters of the FTP channel over to the FTP service in order to accept or reject the connection. If no partner details are found for the client login or the request can not be dealt with for different reasons, the login is rejected.
(11) After a successful login, the FTP service takes the file and sends it to the inner server via the Message Service. This uses a different Message Queue than the Authentication Service.
(12) If a matching profile is registered to this Message Queue in Lobster_data, the file is sent to that profile for further processing.
Note: Steps (11) and (12) are not contained in this document.
Note: The installation software is pre-configured. The entries for the IP addresses in files
./etc/startup.xml respectively ./etc/startup_dmz.xml
./etc/auth.xml respectively ./etc/auth_dmz.xml
./etc/commlog.xml respectively ./etc/commlog_dmz.xml
need to be manually maintained.