Chapter 8. RMI Security

Java RMI (Remote Method Invocation) is one of the oldest and simplest Java APIs for developing distributed applications. As the name suggests, it allows a client program to call methods on remote objects, or objects hosted on a JVM other than the client's JVM. The client and server JVMs need not even be on the same machine. The only requirement is that there must exist some kind of network connectivity, most often one based on TCP/IP, between these machines.^[1]

^[1] Theoretically, it is possible to have RMI over networks other than TCP/IP, although, in practice, most RMI implementations use TCP/IP as the underlying protocol.

RMI allows both client and server programs to stick with the familiar object-oriented programming paradigm, and continue to work with Java objects, method calls, arguments, return values, exceptions, and so on. as if all objects were within the same address space. As we see later, RMI is not completely transparent to the client and server programs and they do need to adhere to certain rules. Still, it is much simpler than socket-based network programming, where the programs must take care of low-level details like socket addresses, connection management, data formats, and so on. The downside to RMI is that both ends, the client and the server, must be written in Java and agree to use the same Java interfaces. But as long as you stick to the Java platform, development of distributed applications is tremendously simplified with RMI. Thanks to Java's inherent support for serializing a category of objects without any explicit help from the programmer and the ability to download code from any URL at runtime, one can write programs that pass around Java objects without having to write special marshaling and unmarshaling methods and worrying about distributing the code. This makes Java RMI much simpler than similar mechanisms in other distributed computing environments such as CORBA.

But is RMI secure? Is it possible to restrict the operations performed by the downloaded code on the host machine? Is it possible for the client to authenticate the server and vice versa? Is it possible to guarantee the integrity and confidentiality of the data being exchanged? Is it possible for the server to selectively allow certain clients to access specific objects and methods?

Except for the first question, for which the answer is a resounding yes, the answers are neither yes nor no. RMI itself doesn't include direct support for authentication, authorization, data integrity and confidentiality. However, with a little effort on the programmer's part, it is possible to write RMI-based applications that use other Java APIs to get these capabilities. We explore this later in this chapter.

You may wonder: Why does RMI lack a comprehensive security model? This is a valid question. The answer lies in the way Java evolved during its early days. It was seen as the language to develop applets, and the security issues of delivering and executing applets got all the attention of Java designers. The focus wasn't on developing conventional distributed applications. Of course, all this changed when Java got a strong foothold in the enterprise. Not surprisingly, there were some attempts to add a security framework to the RMI subsystem by introducing JSR 76, a specification development proposal titled RMI Security for J2SE. However, by this time EJBs, which rely heavily on RMI, and Servlets had taken the prime place as the development platform for enterprise applications. These technologies came with their own security model. Mechanisms to add security to RMI were seen as adding extra complexity where alternatives were available and JSR 76 was eventually dropped.

We have talked briefly about the structure of RMI programs in the section RMI Over SSL, of Chapter 6, Securing the Wire. Essentially, to be able to expose a method for remote invocation, a class must implement a remote interface. Any Java interface that extends the marker interface java.rmi.Remote is a remote interface. Also, all the methods of this interface must throw java.rmi.RemoteException, in addition to other application-specific exceptions. The exception RemoteException represents failures arising out of problems due to the fact that the method invocation is taking place across JVM and perhaps over the network.

Our goal in this chapter is to illustrate RMI security techniques by modifying the base sample application described in Chapter 5, Access Control. Besides the sample application, a lot of other ideas used in this chapter depend on concepts developed in that chapter. For this reason, it is recommended that you go over the Access Control chapter before proceeding further with this chapter.

The first step is to simply extend the base sample application into an RMI-based application. Subsequent sections incorporate security features into the modified RMI-based sample application.