| RMI appears to be a straightforward way of creating a distributed application. But there are a number of security issues. [2] [2] At the time of writing this book, the Java RMI Security Extension is a proposed standard extension to add security to Java RMI. Most of the problems listed here, such as lack of authentication, will be solved by the Java RMI Security Extension. -
RMI has a simple approach to creating the connection between the client and the server. Objects are serialized and transmitted over the network. They are not encrypted, so anyone on the network could read all the data being transferred. -
There is no authentication; a client simply requests an object, or stub, and the server supplies it. Subsequent communication is assumed to be from the same client. -
There is no access control to the objects. -
There are no security checks on the registry itself; it assumes that any caller is allowed to make requests. -
Objects are not persistent; the references are valid only during the lifetime of the process that created the remote object. -
Stubs are assumed to be matched to skeletons; however, programs could be constructed to simulate the RMI network calls, while allowing any data to be placed in the requests. -
Network and server errors will generate Exception s, so applications must be prepared to handle them. -
There is no version control between stubs and skeletons; thus, it is possible for a client to use a down-level stub to access a more recent skeleton, breaking release-to-release binary compatibility. -
A SecurityManager must be set before a remote class can be loaded. For Java applets, the SecurityManager is defined by the Web browser or the Applet Viewer. For Java applications, the SecurityManager can be defined on the command line invocation with the -Djava.security.manager option, or it can be defined programmatically within the application itself. The standard Java API provides a java.rmi.RMISecurityManager class, which merely extends java.lang.SecurityManager but does not make any extra checks. If you require a security policy that is either more or less restrictive , you will need to create your own SecurityManager . If the client and the server are connected through one or more firewalls, additional issues need to be considered (see Section 2.4 on page 36). As we discussed in Chapter 5 on page 157, an enterprise bean is typically accessed using RMI-IIOP, which uses the RMI APIs as just described, but also provides security through the CSIv2 protocol. For the rest, we recommend that you use RMI only in pure intranet configurations or for applications in which it cannot usefully be attacked . An intercompany chat system may be a reasonable use of RMI. Closely coupled internal systems might use RMI, if the appropriate access controls are put in place by network and firewall design. But the lack of authentication and access control in the raw RMI must limit its wider use in secure applications. If you need to create a secure distributed application, you should investigate alternatives to RMI. The CORBA implementations available today provide heavier-weight remote execution methods , and other suppliers can provide alternatives to RMI. |
