RMI Over SSL

Socket-based programming is powerful but quite low-level for developing distributed Java applications. Most often, a programming paradigm based on a client program directly invoking methods on objects within a server program, passing input objects as arguments and getting output objects as return values, is more suitable. Java RMI is one such paradigm.

In its simplest form, an RMI server is a unicast server—meaning it supports point-to-point communication as opposed to broadcast or multicast. It lives within a running process and communicates with clients through sockets, the default being TCP sockets. Programmatically, one creates a unicast server class by subclassing the class java.rmi.server.UnicastRemoteObject. Such a class gets exported at the time of instantiation, or registered to the RMI system, so that method invocations can be dispatched to this object by the RMI system.

By default, the bits encapsulating method invocation, parameters and return values flow over the TCP connection in clear, and hence, suffer from the same security problems. This is not a problem most of the time as RMI is typically used within applications running within an enterprise over a trusted network. However, if you plan to deploy an RMI application over the Internet, or a not-so-trusted portion of an intranet, and are concerned about data security, then RMI over SSL could be a good solution. As we see, this can be accomplished with little programming.

But before we get to the source code to accomplish this, let us review the basic facts: the class UnicastRemoteObject has a constructor that takes three arguments—a TCP port number, a java.rmi.server.RMIClientSocketFactory object and a java.rmi. server.RMIServerSocketFactory object. The server invokes the method createServerSocket() on RMIServerSocketFactory to create ServerSocket object and the client invokes the method createSocket() on downloaded RMIClientSocketFactory (recall that Java byte-code is mobile and can move from one machine to another, in the same way as data) to create a Socket object. The default factories create normal ServerSocket and Socket objects for TCP communication. However, replacing TCP with SSL is a simple matter of supplying the right factories.

Let us look at factory class RMISSLServerSocketFactory to create SSLServerSocket using default SSLServerSocketFactory.

public class RMISSLServerSocketFactory
    implements RMIServerSocketFactory, Serializable {
  public ServerSocket createServerSocket(int port)
      throws IOException {
    ServerSocketFactory factory =
      SSLServerSocketFactory.getDefault();
    ServerSocket socket = factory.createServerSocket(port);
    return socket;
  }
}

The factory class RMISSLClientSocketFactory for client sockets is very similar:

public class RMISSLClientSocketFactory
    implements RMIClientSocketFactory, Serializable {
  public Socket createSocket(String host, int port)
      throws IOException {
    SocketFactory factory = SSLSocketFactory.getDefault();
    Socket socket = factory.createSocket(host, port);
    return socket;
  }
}

If you are well-versed in RMI programming then writing a unicast RMI server class using these factories is trivial. If not, look at the sample code provided with J2SE v1.4 SDK documentation under directory docsguidesecurityjssesamples mi and the instructions to compile and run the programs. The JSTK utility ssltool also includes these factory classes and uses them for communication between client and server when you specify the protocol as SRMI, for Secure RMI. Actually, there in no such protocol as SRMI, this is a term that I coined to refer to RMI over SSL.

More information on RMI security and working examples can be found in Chapter 8, RMI Security.

Recall that the default SSLServerSocketFactory and SSLSocketFactory rely on system properties to locate the certificate and truststore. So an RMI program using these factories would expect the appropriate system properties to be set. You can override this behavior by supplying your own KeyManager and TrustManager. Look at the source files within JSTK for complete working code.