Overview

Problem

In the current client/server architecture of ENOVIA, client applications contact the servers using GIOP protocols (proprietary Orbix protocol or standard IIOP) which require a different port for each server to be contacted.

Here is a schematic view of the current configuration:

This architecture is well adapted to LANs (Local Area Networks) and Intranets, in which client and server hosts can connect to each other directly without going outside the corporate network. This is not the case for WANs (Wide Area Networks) and Extranets, in which client and server hosts have to cross network devices such as gateways and firewalls to connect to each other. The role of these (hardware or software) devices is to guard the borders of the corporate network from the Internet by enforcing rules controlling which client host (IP address) can connect to which server host (IP address) on which port.

To continue working, the above architecture supposes that a wide range of ports (currently 200) are open both on the client-side firewall (to let go out connections to known server hosts on authorized ports) and on the server-side firewall (to let come in connections from known client hosts on authorized ports). This is problematic in terms of security and administration.

Solution

This solution comes with its specific components and processes to be started on client and server hosts, ahs has its own advantages and constraints that we detail below.

However, it requires that ONLY ONE additional port be open on the firewalls standing between the client and the server networks, instead of the wide range of ports used by GIOP-based protocols. This port can be chosen arbitrarily by the administrator of the server network (a default is provided) and the clients will comply with this choice to administrate their own network security.

Technically, the solution is based on port redirection performed in the TCP protocol layer: each connection to a given port is finally redirected to the tunneling port open on the firewalls. All GIOP-based communications will occur through this dedicated port.

Warning: Apart from Intranet usage, you MUST use the HTTP tunneling solution. Any incidents relating to firewalls or proxies will not be taken into consideration.

HTTP Tunneling

Advantages

1. No dedicated host needed on the server side: the server component runs on each server host thanks to small memory overhead
2. Client and server components have no impact on application code at all
3. Only HTTP packets cross the firewalls
4. Support HTTP proxy and reverse proxy servers
5. The solution is quite easy to deploy and administrate: just one file to edit to activate port redirection, one client process to configure, and one server process to configure, start, and control.
6. It's possible to activate SSL security and encryption on the HTTP solution:
   • Strong authentication: support of public key cryptography and certificates
   • Data confidentiality: only encrypted packets cross the network and the firewalls
   • Data integrity: support of message digest algorithms
7. Apart from SSL configuration, the secured solution is also easy to deploy and administrate: just one file to edit to activate port redirection, one client process to configure, and one server process to configure, start, and control.

Constraints

1. An additional process is running on the client host. However this process is automatically started. Nevertheless, it might require some control whenever the provided fail-over mechanism is out.
2. CPU and network overhead on the client and server sides due to the additional handling of HTTP semantics.
3. SSL configuration: acquire a certificate for each server host, configure clients to accept the server certificate (Optionally: acquire a certificate for each client host, configure servers to accept the client certificate). The HTTP proxy server must allow the HTTP CONNECT method on the SSL port.