Interfaces and Architectures
In the previous post We have discussed two parts of the world of Java, the development environment and the execution environment. The third part is where the world of Java meets the rest of the world, that is, the capabilities it provides for extending Java functions and integrating with applications of other types. The simplest example is the way that a Java applet is created and integrated into a Web page by writing the program as a subclass of the Applet class and then specifying the class name in an <APPLET> HTML tag. In return, Java provides classes such as URL and a number of methods for accessing a Web server.
Don’t Go Native! Seek Purity!
Another simple way to extend Java is by the use of native methods. These are sections of code written in some other, less exciting, language which provides access to native system interfaces. For example, imagine an organization with a helpdesk application which provides a C API for creating new problem records. You may well want to use this so that your new Java application can perform self-diagnosis and automatically report any faults it finds. One way to do so is to create a native method to interpret between Java and the helpdesk application’s API. This provides simple extensibility, but at the cost of portability and flexibility, because:
• The native method has to be compiled for a specific system platform.
• It must be pre-installed and cannot be installed dynamically like a Java applet.
The Java purist will deprecate this kind of application. In fact, although the quest for 100% Pure Java 2 sounds like an academic exercise, there are a number of real-world advantages to only using well-defined, architected interfaces, not the least of which is that the security aspects have presumably already been considered.
Some of the Roads to Purity
As projects using Java have matured from being interesting exercises in technology into mission-critical applications, so the need has arisen for more complex interactions with the outside world. The Java applet gives a very effective way to deliver client function without having to install and maintain code on every client. However, the application you create this way still needs access to data and function contained in existing legacy systems.
With JDK 1.1, JavaSoft introduced a number of new interfaces and architectures for this kind of integration, which have been enhanced on the Java 2 platform. The objective is to enable applications to be written in 100% Pure Java, while still delivering the links to the outside world that real requirements demand.
Some of the more notable interfaces of this kind are:
• JavaBeans
the JavaBeans technology not only provides easier application development, but also provides integration with other distributed object architectures. From a security point of view this capability opens a back door which an attacker could exploit. The Java security manager provides strict and granular controls over what a Java program may do. But these controls are dependent on the integrity of the JVM and in particular the trusted classes it provides. A Java applet might not be able to meddle with the trusted classes directly, but a Bean can provide linkage to a different type of executable content, with less stringent controls. This could be used to corrupt the JVM trusted classes, thereby allowing an attack applet to take over.
• Remote Method Invocation
Remote Method Invocation (RMI) allows a Java class running on one system to execute the methods of another class on a second system. This kind of remote function call processing allows you to create powerful distributed applications with a minimal overhead. For example, an applet running on a browser system could invoke a server-side function without having to execute a CGI program or provide its own sockets-based protocol.
The security concerns for RMI are, in general, similar to the CGI case. For example, consider a Java application that accesses a database of personal information, consisting of a server-side application communicating with a client applet. When writing the application, the programmers will naturally assume that the only code involved is what they write. However, the Java code that initiates the connection does not have to be their friendly applet, it could be the work of a cracker. The server application must be very careful to check the validity of any requests it gets and not rely on client-side validation.
RMI has several new enhancements on the Java 2 platform. Remote object activation introduces support for persistent references to remote objects and automatic object activation by using these references. Custom socket factories allow a remote object to specify the protocol that RMI will use for remote calls to that object. RMI over a secure transport – such as Secure Sockets Layer (SSL) – can be supported using custom socket factories. Minor API enhancements allow unexporting a remote object, obtaining the stub for an object implementation, and exporting an object on a specific port.
• Object Request Brokers
RMI provides a way to remotely execute Java code. However, for many years the O-O world has been trying to achieve a more generic form of remote execution. That is, a facility that allows a program to access the properties and methods of a remote object, regardless of the language in which it is implemented or the platform on which it runs. The facility that provides the ability to find and operate on remote objects is called object request broker (ORB). One of the most widely-accepted standards for ORBs is the Common Object Request Broker Architecture (CORBA), and packages are becoming available that provide a CORBA-compatible
interface for Java. Figure 26 on page 53 illustrates the relationship between a Java application or applet and a remote object. Clearly, in an implementation of this kind the Java program relies on the security of the request brokers. It is the responsibility of the ORB and the inter-ORB communications to authenticate the endpoints and apply access control. The official standard for inter-ORB communications is the Internet Inter-ORB Protocol (IIOP).
Figure : Interacting with an ORB
• JDBC
JDBC ought to stand for Java Database Connectivity, but actually it is a name in its own right. JDBC is an API for executing SQL statements from Java. Most relational databases implement the Open Database Connectivity (ODBC) API, originated by Microsoft. JBDC thoughtfully includes an ODBC bridge, thereby giving it instant usefulness. From a security point of view, there are some concerns. You should beware of giving access to more data than you intended. For example, imagine an applet which invokes JDBC on the Web server to extract information from a database. It is important that the server application is written to allow only the SQL requests expected from the applet, and not the more revealing requests that an attacker could make.
