|The solution exposed in this document is
based on HTTP-tunneling technique. HTTP tunneling consists in wrapping
application layers (here IIOP messages) in HTTP requests and responses. The
main advantage of this technique is that most firewalls may be configured
to accept HTTP messages.
Unlike the "port redirection only" solution, the provided HTTP-tunneling component implies some performance overhead due to the additional handling of the HTTP protocol semantics. Though, it still has no impact on application code and remains easy to deploy and administrate.
The proposed global solution is made of four parts (one of which is
As far as the server network is concerned, no additional configuration is needed since the port 80, dedicated to the HTTP protocol by standard, can be used. However, this is not mandatory and any other port can be used, provided it is open on the firewall. On this server-side, both direct and tunneled connections are allowed with the same Orbix daemon. All servers and clients lying inside the firewall can connect to all other servers without tunneling.
|Network security, and especially user authentication, is still managed by the corporate firewall and/or HTTP proxy server, that enforce rules controlling which client can connect to which server on which port. In particular, the tunnel client process is able to handle authentication challenges from the HTTP proxy server (only base-64 "Basic" authentication is currently supported).|
|The HTTP and HTTPS (SSL) Tunneling solutions
can be totally integrated in a traditional Web-oriented network
infrastructure. On the server side, this kind of network infrastructure is
generally composed of a De-Militarized Zone (DMZ), protected by a first
firewall, that hosts servers (Web servers, DNS servers, ...) directly
accessible from the Internet. Then a second firewall protects the internal
network that hosts back-end servers accessible only from the DMZ. Generally
only HTTP port 80 and HTTPS port 443 will be open on the firewalls, hence
the need for tunneling non HTTP traffic.
As far as Web servers are concerned, in many cases the Web server itself is not present in the DMZ but is located in the internal network and is represented in the DMZ by a Reverse Proxy server. A Reverse Proxy server is the server-side equivalent of a Proxy server: its role is to represent the server from the client point of view just like the Proxy server represents the client from the server point of view. This kind of infrastructure is much more secure and allows features such as load balancing.
We will base all the following deployment on the most common and general Web-oriented network infrastructure that may exist on a site wishing to share its servers with the external network. Here is a logical representation of this assumed network topology:
As can be seen, we consider three different network domains: the external domain of the client applications, the domain of the DMZ (hosting a Reverse Proxy server in particular), and the internal domain of the server applications. The internal domain cannot be seen from the external domain, only the DMZ domain can. Notice that on the client side, a Proxy server can be deployed but its role does not change the preceding considerations about the network. It is just an optional representative of a client host. We suppose also that each domain comes with its own Domain Name Service (DNS) allowing to locate a network host in this domain from its fully qualified domain name (FQDN).
The Reverse Proxy server can be secured or not, that is, be listening on open port 80 and/or 443. If it is secured, SSL protocol requires that it has a valid certificate to be presented to the SSL clients for acceptance. The Reverse Proxy server can in turn connect to the back-end servers using secure protocol or not. In the first case, the back-end servers must have a valid certificate to be presented to the Reverse Proxy server for acceptance. Though this kind of configuration is supported by the current SSL Tunneling solution, we will not deal with it in our example. We will make the simple assumption that the Reverse Proxy server connects to the back-end servers using open HTTP port 80. This avoids managing SSL intricacies on the back end, performance overhead, and so on.
Enabling HTTP tunneling
A first variable named CATProxify has to be valuated to a comma-separated list of <hostname>:<tunneling port> to reference all the servers to be contacted behind the firewall through some specified tunneling port numbers. By default, all messages are redirected to port 12872 (not 80).
ENOVIA V5 VPM and Vault servers are to be contacted respectively on ports 12872 and 12345. These ports have to be open on the firewalls.
ENOVIA V5 VPM and Vault servers are both to be contacted on port 80, which is a commonly open port on firewalls.
In addition, a second variable named CATProxyGateway has to be valuated with a single host / port couple as <gateway host>:<gateway port> to reference the host name and port number where the tunnel client process is running (see below). We strongly recommend that a tunnel client process runs on each client host, so that <gateway host> be always set to "localhost" (this is in particular mandatory to impose individual HTTP proxy authentication). Default port is set to 18271.
Note: "localhost" is a common machine name alias declared by the operating system to represent the local machine.
According to the client application, two methods exist to set these two variables. For CATIA clients for interoperability, they have to be added to the CATIA runtime environment file using the Environment Editor. For clients, they have to be set in the file corbaProxy.properties located in the directory <Install Path>/docs/java.
The starter process
Each client host has to act as a gateway (see CATProxyGateway variable). Actually, the tunneling gateway process is started by a dedicated process named "CATTunnelStartup." The role of this process is to start and control the lifecycle of the tunneling gateway process which is in charge of alternatively wrapping all outgoing IIOP requests into HTTP requests and unwrapping all incoming HTTP responses back into IIOP responses.
CATTunnelStartup is automatically launched if and only if the following variables are properly set in the runtime environment of the client process:
Note that the file name and the file path properties can be customized and be different from the above default values. However it is mandatory that the file name at least contains the string "Client".
The file name and file path properties point to the provided file CATTunnelStartupClient.conf located in <Install Path>/docs/java. The role of this file is to list the commands to be launched by the starter process CATTunnelStartup.
Configuring the HTTP-tunneling gateway process
The configuration of the tunneling gateway process itself is made in a dedicated file. That's why the command line is not to be modified except to set extra properties specific to the JVM.
The file to configure the HTTP tunneling process is pointed to by two environment variables to set its name and its location on the file system. Both variables are optional. Their default values are listed below:
The file CATTunnelClient.conf is provided and is located in <Install Path>/docs/java. The content of this file is a series of properties that set the behavior of the HTTP tunneling process and have to be customized. There are two kinds of parameters in this file : the general parameters and the security parameters.
We here detail all the general parameters that can be set in the HTTP client process configuration file. You can open it to follow the explanations and to customize it:
The starter process
On all server hosts where ENOVIA servers are running, a starter process named "CATTunnelStartup" needs to be running. Its role is exactly reciprocal to the role of the client starter process: start and control the HTTP server process which is specifically in charge of alternatively encoding all outgoing IIOP responses and decoding all incoming IIOP requests.
The following variables must be properly set in the environment of the starter process. These variables can be exported in the server environment file whose name is given in <Install Path>/EnvName.txt and location is given in <Install Path>/EnvDir.txt.
Note that the name and the location properties of the file to configure the starter process can be customized and be different from the above default values. However it is mandatory that the file name at least contains the string "Server".
The file CATTunnelStartupServer.conf provided in
When the environment variables are set, the process CATTunnelStartup have to be started with the "catstart" command such as:
The HTTP server process
The configuration of the HTTP server process itself is made in a dedicated file. That's why the command line is not to be modified except to set extra properties specific to the JVM.
The file to configure the HTTP server process is pointed to by two environment variables to set its name and its location on the file system. Both variables are optional. Their default values are listed below:
The file CATTunnelServer.conf is provided and is located in
We here detail all the general parameters that can be set in the HTTP server configuration file (you can open it to follow the explanations and customize it).
Summary of the Overall Deployment without Proxy
To sum-up the preceding points here is now an example of a typical deployment, going from the server to the client.
Let's suppose there are two hosts, named "S1" and "S2", and having private IP addresses "IP1" and "IP2" respectively on the local network. On "S1" a ENOVIA V5 VPM server will be running, with Orbix daemon port 1570 and a range of IIOP ports from 1590 to 1790. The logical name "LCA" is given to this server in the Orbix configuration file. On "S2" a Vault server will be running, with Orbix daemon port 2570 and a range of IIOP ports from 2590 to 2790. The logical name "Vault" is given to this server.
Each server environment file is updated to configure the process CATTunnelStartup for the server side (name from <Install Path>/EnvName.txt and location from <Install Path>/EnvDir.txt):
On each host the starter process is launched like this:
ENOVIA V5 VPM:
The files CATTunnelServer.conf are updated to start the process with the following arguments:
ENOVIA V5 VPM:
On the client network, suppose a HTTP proxy server running on a host named "MyHttpProxy," on typical port 8080. This proxy is configured to let go out only authorized users. Moreover it is configured to authorize the CONNECT method on port 80 between the internal network (or a part of it) and IP address "IP0" (this is almost MANDATORY).
For the ENOVIA VPM Product Editor client application, the corbaProxy.properties file is updated like this:
For the CATIA application, the same variables are exported in the runtime environment. On each client host, before running any application, the process "CATHttpTunnelClient" is configured like this by editing the file CATTunnelClient.conf :
When beginning an ENOVIA VPM Product Editor client session, besides userID and password, the user types the following server name: "LCA:1570." Moreover, in the VaultClient.properties file, the Vault server host name and daemon port have been set to "Vault" and "2570", respectively.
From now on, everything should be transparent from the client point of view, except for the HTTP proxy server authorization panel, that appears for the user to enter his / her Internet id and password just after login.
Example of the overall deployment with Internet proxy and reverse proxy servers
To make clear the new deployment of the HTTP Tunneling solution, an example of a typical deployment is presented and explained step by step, going from the server side to the client side.
Our purpose is to go from the back end to the front end and see at each step what is required to deploy the HTTP Tunneling solution successfully.
General DNS configuration
Three domains are present on the network:
Here is what could be found in the DNS records of the:
1. supplier domain:
2. oem public domain:
3. oem private domain:
(We use private addresses 192.168.x.x for illustration purpose only. Of course they are irrelevant in the context of Internet.) FQDN of hosts pertaining to the oem public domain (e.g. www.dmz.com) can be resolved from anywhere in the network. On the contrary, FQDN of hosts pertaining to the oem internal network (e.g. enolca001.oem.com) can only be resolved from the internal network itself and from the DMZ.
To permit the client hosts to contact the ENOVIA V5 VPM servers, the FQDN of the machine hosting the servers MUST be resolvable from the client network. Hence a record has to be added to the public DNS server of the oem company:
It is mandatory that the Reverse Proxy and
ENOVIA V5 VPM servers share the same
public IP address for the HTTP Tunneling solution to work.
Overview of the solution
Here follows a schematic representation of what happens to the ENOVIA V5 VPM messages using the HTTP Tunneling solution:
Three network hosts are represented along with the running processes of interest:
1. the client host (running the
ENOVIA VPM Product Editor client application, the HTTP
Tunneling client process);
The HTTP Tunneling client process is speaking to the Reverse Proxy server in HTTP. ENOVIA V5 VPM IIOP messages are redirected to the HTTP Tunneling client process that eventually handles:
Then the Reverse Proxy server is speaking to the HTTP Tunneling server process which finally dispatches them to the right applicative server process (in IIOP). We will now detail the configuration of each box.
Configuring the server host
Let's suppose a host named enolca001 located in the internal network of the oem company, with operating system IBM AIX.
This host has a private IP address that can be resolved from the internal network and the DMZ using a DNS lookup on the FQDN enolca001.oem.com. However, as seen in the DNS configuration setup, from a client point of view, this host has also a public IP address (the one of the bastion host) that can be resolved from anywhere using a DNS lookup on the FQDN enolca001.dmz.com.
On this machine, ENOVIA V5 VPM servers will be running: the Orbix daemon will be listening on port 1570 and each applicative server on a port ranging from 1590 to 1789. Hence we start the HTTP Tunneling configuration after a standard ENOVIA V5 VPM installation has been done as explained in the dedicated product documentation. This supposes in particular that a JRE 1.3 be present and correctly installed on the machine.
Let's say that the ENOVIA V5 VPM installation is located in the directory <InstallPath>, which could be something like:
Orbix daemon configuration
1. To support that ENOVIA V5 VPM servers and Reverse Proxy server belong to two distinct domain names, the Orbix configuration has to be modified.
Change the following Orbix parameters in file
and in the file
Then edit the file /etc/hosts and add enolca001.dmz.com at the end of the server host's IP address line, so that:
should now read:
The Orbix daemon must be restarted to account for its new configuration.
HTTP Tunneling server process configuration
2. Edit the file <InstallPath>/docs/javaserver/CATTunnelServer.conf to configure the HTTP Tunneling server process.
(Note: you can also adapt the forwardPorts parameter to match the actual port range of the ENOVIA V5 VPM servers declared in the Orbix configuration.)
3. Set the three environment variables CATTunnelingMode, CATTunnelingPropertiesFileName, and CATTunnelingPropertiesFilePath in the file whose name is given in <InstallPath>/EnvName.txt and location is given in <InstallPath>/EnvDir.txt:
4. Launch the starter process CATTunnelStartup with the following command line:
Check that the Java process is running.
This step ends the configuration of the server host.
Configuring the bastion host
In this section we illustrate the installation and the configuration of a Reverse Proxy server. We assume that this server is an Apache server. As already stated, these steps are intended to anyone
1. Make sure GZip and Perl are installed and accessible through the
commands gzip and perl.
3. Extract in directory /usr/src the required package:
4. Build the Apache Web server:
5. Configure the Apache Web server with the virtual host feature.
Edit the Apache configuration file /usr/local/apache/httpd.conf and add the following lines:
6. Restart the Apache Web server:
Note: the Reverse Proxy server can be configured to issue an authentication challenge to the end user using HTTP code 401. In that case, the HTTP Tunneling client process will prompt the user for an ID and password (the so-called Basic authentication is the only supported scheme).
This step ends the configuration of the bastion host.
Configuring a Forward Proxy server (optional)
In most companies, Proxy servers are present to allow end users to go outside the internal network. We illustrate here the installation and the configuration of a Proxy server. It will be configured to issue an authentication challenge to the end user using HTTP code 407. In that case, the HTTP Tunneling client process will prompt the user for an ID and password (the so-called Basic authentication is the only supported scheme). We assume that this server is an Apache server. As already stated, these optional steps are primarily intended to anyone
1. Make sure GZip and Perl are installed and accessible through the
commands gzip and perl.
3. Extract in directory /usr/src the required package:
4. Build the Apache Web server:
5. Generate user ID and password for Basic authentication (replace <UserID> and <UserPwd> with actual values):
6. Configure Apache Web server with authentication and cache features:
Edit the Apache configuration file /usr/local/apache/httpd.conf and edit / add the following lines:
Note: if the HTTP CONNECT method is to be allowed on port 80 (using the Apache directive AllowCONNECT 80 in the above httpd.conf file) then you can set to false the related parameter of file <InstallPath>\docs\java\CATTunnelClient.conf that configures the HTTP Tunneling client process (see Configuring the client hosts section below):
This will significantly increase network performance since the Proxy server will be transparent as far as HTTP protocol is concerned.
7. Restart the Apache Web server:
This step ends the configuration of the optional Proxy server host.
Important Note: To reduce the overhead introduced by HTTP protocol, HTTP Tunneling uses the Keep-Alive feature of HTTP/1.1, that is it reuses the same TCP connection to send several messages. But as seen in the current deployment of the solution, on the path from the client host to the server host, there can be at least one or two Web servers. These Web servers can be configured to restrict the number of messages that can be send on the same TCP connection before closing it (for Apache Web server the parameter to tune is MaxKeepAliveRequests). In some scenarios (when downloading huge or numerous models for example), it is possible that the number of messages exceeds this limit and the tunnel gets broken. Hence be sure that MaxKeepAliveRequests or equivalent be as high as possible on each traversed Web server to avoid such a shortcoming. Alternatively, the packet size of the ENOVIA V5 VPM messages can be increased so that:
Configuring the client hosts
We suppose that the client machines have Windows for operating system. We start the HTTP Tunneling configuration after a standard ENOVIA V5 VPM installation as explained in the dedicated product documentation. Let's say that the ENOVIA V5 VPM installation is located in the directory <InstallPath>, which could be something like:
On the client network, we suppose that the Proxy server described above is running on a host named proxy and is listening to port 8080. This Proxy server is configured to let go out only authorized users with valid user ID and password.
HTTP Tunneling client process configuration
1. Edit the file <InstallPath>\docs\java\CATTunnelClient.conf to configure the HTTP Tunneling client process. Add the lines:
2. Set the three environment variables CATTunnelingMode, CATTunnelingPropertiesFileName, and CATTunnelingPropertiesFilePath in the file whose name is given in <InstallPath>\EnvName.txt and location is given in <InstallPath>\EnvDir.txt:
3. Edit the file <InstallPath>\docs\java\corbaProxy.properties to enable port redirection on the client side and set:
When beginning a ENOVIA VPM Product Editor client session, the user has to type the server name and port as:
The CATTunnelStartup process will be automatically started by the ENOVIA VPM Product Editor client application and will control the HTTP Tunneling client process. The user will have to type his/her ENOVIA V5 VPM user ID and password in the logon CATlet, his/her Internet user ID and password (to pass the Proxy server), and eventually to type his/her secondary Internet user Id and password (to pass the Reverse Proxy server). From now on, everything should be transparent from the user's point of view.