ObjectWall is a proxy firewall developed specifically for IIOP. In this short white paper, we will illustrate that ObjectWall is superior even to the most advanced combination of various security technologies currently available on the market to support performance and interoperability of the IIOP protocol.

In the following, we will discuss the possibility of using another technology or a combination of other technologies instead of ObjectWall. We show that it is not easy to find a good alternative to ObjectWall, and that the alternatives are technically very restrictive. This is because alternative approaches put unusual requirements on technology deployment, while not even providing the complete ObjectWall functionality.

We will illustrate that ObjectWall is superior even to most advanced combination of various security technologies available on the market to support performance and interoperability of the IIOP protocol.

Example Scenarios

First we describe two scenarios which we will use to compare the actual technology and the technology combination:

Scenario 1: The first one is simple client-server scenario where the server is behind the firewall. ObjectWall will be configured with one acceptor interface on the outside and one initiator interface inside. During the start-up it will process the bootstrap object reference of the server which will be provided to the client.

Scenario 2: The second scenario is more complex because it involves a client with callback functionality, and we also assume that client's machine is publicly accessible from the internet. Here, ObjectWall will not only need to support the same configuration as in the first scheme, but will also need to provide one accepting interface inside and one initiator interface outside to be able to provide the server side with the possibility to invoke client-side callback objects.

Compared technology alternatives

The list of technologies for the comparison is:

1. SSH and SSH tunnelling: when SSH is enabled on the target side and when it is allowed in by the target firewall, then the client might use SSH to "tunnel" its TCPIP connection to the servers hidden behind the target firewall. The assumption is that the tunnelling option is switched on.

2. Forward IOR generation: this is an ORB functionality that ensures that the generated IORs will contain a specified “host:port” combination instead of the “host:port” of actual TCPIP socket. Note: not all CORBA implementations support this option.

3. Direct firewall packet forwarding: this functionality is commonly used for NAT and for the so-called default server behind the NAT box. Also nearly every firewall software allows packet forwarding from some port of the outside interface to some other “host:port”.

4. SOCKS forwarding: The SOCKS technology is useful for clients behind the firewall that need to connect to some publicly accessible system on the internet even though their firewall machine does not allow such communication. The common practice is to use a SOCKS server which is allowed to connect remote/outside and a SOCKS library on the client side that, instead of opening real connection to the target, opens connection to the SOCKS server and instructs it about the real target of the connection.

5. IIOP tunnelling over HTTP: this approach assumes that most firewalls allow inbound communications on port 80 and tries more or less successfully to tunnel IIOP messages over plain HTTP protocol.

Comparison

Now we will evaluate how these technologies compare against the simplicity of ObjectWall setup in both described scenarios.

SSH: We will start with SSH and its forwarding capabilities.

In the first scenario, we need to start the server binding to the localhost and also to the real host network (outside) interface. We provide the client with the server bootstrap IOR. The client will need to find out server's port either by consulting the server side management (the server side will make port number publicly available, e.g. on a web site) or by decoding the server's IOR (by using some IOR decoding tool like such as MICO’s iordump). Then the client will need to start the SSH tunnel (using "ssh -L port:host:port -l name -N host" where “host” is the target machine, “port” is the port which is presented in IOR and “name” is the user name under which we're able to login to the host). When this is done, the client is able to connect thorough “localhost:port” which will use the ssh tunnel to the real “host:port”. The obvious limitation of this approach is that the target server and the SSH daemon need to be collocated on the same machine.

In the second scenario, there are two possibilities of how things might be done: (a) if target server is able to reach the client machine, then the setup will be the same like in the first scenario.(b) If this is not the case and the target server firewall will not allow server communication out, then we will need to use some other tunnelling mechanism like BiDirGIOP (if it is available and acceptable) or SOCKS, which will put another burden on the setup management.

Advantages: this is technically possible

Disadvantages: complex setup involving ssh in the first case, and either BiDirGIOP or SOCKS in the second case. It is also not possible to use more than one CORBA server per SSH tunnel. This makes this approach even more limited in the case of a server pool and e.g. naming service usage, both of which ObjectWall supports naturally. The biggest limitation is the need to collocate the CORBA server and the SSH daemon.

Direct firewall packet forwarding: In this case, we will to solve the requirement to collocate the SSH daemon and the CORBA server on the same machine. On the other hand, the discussed setup is not possible without the forward IOR generation functionality.

In the first scenario we will need to start the server and forward generate its IOR so that it "points" to the outside interface of the firewall machine. We also need to make sure that the communication to that end-point is possible and that the communication is then sent/forwarded to the machine hosting CORBA server.

In the second scenario things are very similar to the SSH setup. We need to have the same setup as in the first scenario, and if the target server is able to reach the client machine, then everything is fine and callbacks will work. On the other hand, if this is not the case and the target server firewall will not allow outbound server communication, then we will need to use some other tunnelling mechanism like BiDirGIOP (if available and acceptable), or SOCKS like in the case of the SSH approach.

Advantages: this is technically possible, and no need to collocate the firewall functionality with the CORBA server.

Disadvantages: complex setup that involves tweaking with the firewall and its packet forwarding configuration. In the second case, either BiDirGIOP or SOCKS are required in the case where the client side is not reachable. It is also not possible to use more than one CORBA server per port forwarded on the firewall. This limits the usefulness of this approach in the case of a server pool and e.g. naming service usage.

IIOP messages tunnelling over plain HTTP: This approach seems to a be very good option at first sight. It allows using already existing infrastructure like HTTP proxies and HTTP firewalls (firewalls set to allow inbound HTTP communication).

In the first scenario we will need to configure the web server to provide some URL entry point which will be used to process incoming HTTP-based CORBA messages. It might either be a CGI, servlet or some other kind of code executed as part of the web server. We can either start the server directly on our web server machine or we can use some kind of proxy forwarder where the web server-based code will just process the incoming HTTP request and forward it to the real server using the IIOP protocol. As all those setup points are highly product dependent, we will not describe any actual configuration here.

In the second scenario, we will need to configure the web server as in the scenario above, but also add some options for allowing the server side code to invoke client side objects. Again this is highly product dependent and therefore we will not describe any concrete setup details here.

Advantages: this is technically possible, and uses the infrastructure which is already deployed: web servers, proxies, firewalls

Disadvantages: this is a proprietary solution not standardized by the OMG. It is not interoperable and performance suffers here because of the need to marshal/unmarshal from/to HTTP. Depending on the product in use, the setup might be quite complex.

 

Conclusion

The most important conclusion is that, in comparison to ObjectWall, access control is insufficient in all these alternatives. SSH provides only very rough access control limited to user access per GIOP connection created. This is much less fine-grained than ObjectWall's per invocation access control. The same applies to IIOP tunnelling over HTTP in the case of HTTPS instead of simple HTTP.

Another weakness in comparison with ObjectWall is that, except possibly IIOP tunnelling over HTTP, these alternative approaches are very limited with respect to the number of supported CORBA servers. If there is more than one, then some additional setup tuning is always needed. In case of approach IIOP tunnelling over HTTP, the application also suffers from a performance point of view.

Moreover, as opposed to ObjectWall, none of the described technology alternatives support additional GIOP message correctness checking (like message size).

In summary, this comparison shows that ObjectWall is by far the best solution for IIOP firewall traversal.

April 2006

The full list of available publications about ObjectWall is available in the resources section