2.1 Networked Architectures

The most common architectural approaches for today's enterprises are the two- and three- tier models.

2.1.1 Two-Tier Architectures

In a two-tier architecture , two applications ”the client and the server ”exchange information over a network. The client makes requests to the server, and the server sends responses back to the client. Such responses can contain any combination of static and dynamic information. Static responses are identical for each client, such as static HTML documents. Dynamic responses are generated based on the particular input from the user ; the generation of a dynamic response requires a program running on the server. To perform transactions, the server may need to access a database.

In a Web environment, the client application is usually a Web browser, and the server application is a Web server. The Web browser can be enhanced by a number of plug-ins, including a Java Plug-in to run applets. The Web server can be enhanced by a servlet container, an EJB container, and other transactional applications, as discussed in Section 2.3 on page 32.

Perhaps the simplest use of a Java application in a two-tier architecture is the browser add-on Java virtual machine (JVM) to run applets and extend the facilities provided by a Web browser. Applets may be used to enhance the user interface by providing interactivity, such as context-sensitive help or local-search functions. Applets may also be used to handle additional data types, such as compressed astronomical images or packed database records. These examples depend directly on the Java security architecture, which prevents unauthorized access to protected resources.

The next level of complexity is seen in network-aware applets, which perform network operations other than simply reading data. Terminal emulators are in this category. These applets provide the functions of a nonprogrammable terminal, or visual display unit (VDU), connected via a local area network (LAN) to a z/OS or Application System/400 (AS/400) host system, where the applications are run. An example is IBM Host On-Demand, which emulates a 3270 or 5250 mainframe display session, communicating with a mainframe over TCP/IP. Figure 2.1 shows an IBM Host On-Demand system.

Figure 2.1. IBM Host On-Demand System

When run as applets, such programs are subject to the restrictions imposed by the Java authorization mechanisms. By default, they may open a network connection only back to the system from which they were downloaded. However, terminal emulation programs usually need to communicate with many different host systems, not just one. If the host is a large mainframe, crucial to business, its owners may be reluctant to install the TCP/IP software, preferring to remain with Systems Network Architecture (SNA) LANs. On other host systems, it might not be desirable to install, configure, run, and maintain a Web server simply to download the Java emulator applet, and this approach would still restrict access to that single host.

The Java 2 security architecture solves that problem. It is still true that downloaded applets are restricted to connect back only to the system from which they are downloaded; that is the default configuration. Using the fine-grained Java 2 access control mechanisms, it is possible to modify this default restriction. Java system administrators can specify the range of socket connections that a particular Java program is allowed to use. Java 2 supports a declarative policy configuration, which means that the policy definition can be external to the application. Therefore, modifying the default restrictions does not require hard-coding the security policy in the application or altering the Java system's security manager, which is implemented as a java.lang.SecurityManager object. This makes it easy to change the policy, extend the application, and port the application to various platforms.

Another possibility is to run the Java emulator as a stand-alone application, thereby relaxing the restrictions on which hosts the emulator may connect to. This is the classic two-tier client/server application architecture. The security issues are very similar to running any other executable program, namely, that it is wise to use only trusted sources of programs. Java technology has several safety and security advantages over other binary programs; its executable files and digitally signed Java programs can provide a cryptographic guarantee about the code author's identity.

2.1.2 Three-Tier Architectures

Another design is to run middleware software on the Web server. The client will communicate over TCP/IP with the middleware software, which can then pass through the messages to the ultimate destination. For example, in the case of 3270 terminal emulation, IBM's Communications Server, which runs on several operating systems, can provide the TCP/IP connection to the Java 3270 Terminal Emulator and can connect to hosts over both TCP/IP and SNA. Figure 2.2 shows the architecture for this three-tier client/server application.

Figure 2.2. Three-Tier Architecture Example

Another possibility is to use Web server CGI programs ^[1] to provide the middle tier. The IBM CICS Internet Gateway takes this approach: to the application server, emulating the functions of a 3270 terminal but downstream, generating HTML code, which is displayed in the Web browser window (see Figure 2.3). This approach avoids using Java technology in the client but does not provide as much flexibility, as the display is restricted to what can be done in HTML.

^[1] Often termed CGI -BIN programs after the name of the directory in which they are conventionally stored.

Figure 2.3. CICS Internet Gateway

A better design, described in Section 2.3 on page 32, is to use Java servlets and/or JSP applications in place of CGI programs in the middle tier and then take advantage of the J2EE and J2SE security services. The servlet and JSP programming model offer a simple way to present data to the client by generating HTML and/or XML code that is sent to the client, based on the client/server interaction. Servlets and JSP applications can interact with EJB components via Java RMI-IIOP (see Appendix A on page 547). The JDBC protocol allows interaction with databases. This architecture is shown in Figure 2.4.

Figure 2.4. Three-Tier Architecture Using Servlets and EJB Technology

The gateway server approach can also be used to provide extended facilities to Java applets. The IBM CICS Gateway for Java is a good example of this; it allows a Java applet to access transaction-processing capabilities of CICS servers running on a variety of server platforms. The IBM CICS Gateway for Java provides a class library package to access CICS functions. The class library itself does not perform the bulk of the functions; instead, it transmits the request to the gateway server and returns the server's response to the applet. The gateway server is a small program that receives the requests and calls the CICS client library, which communicates with the CICS system itself.

The CICS transaction-processing engine is commonly run on its own system, separate from the Web server, as shown in Figure 2.5. The CICS client application, residing on the midlle tier, and the CICS server applications, located on the third tier, communicate using the External Presentation Interface (EPI) and the External Call Interface (ECI). Several communication protocols are supported, such as TCP/IP and Network Basic Input-Output System (NetBIOS). The CICS client and the CICS server application can also communicate through Advanced Peer-to-Peer Communication (APPC), an application programming interface (API) for peer-to-peer communication on SNA.

Figure 2.5. CICS Gateway for Java Example

Enforcing security for the type of system shown in Figure 2.5 is more complex. The security of both the gateway system and the systems with which it connects must be ensured, especially if the server is on the public Internet, where any malicious hacker may attempt to access it. Intranet systems should already have some defenses in place to restrict access to company personnel, but security is still of concern, especially if sensitive data is at risk.

The usual approach is to provide a number of barriers that must be overcome before data access is granted. Often, the first barrier is the company's firewall system. As discussed in more detail in Section 2.4 on page 36, a firewall is a system combining hardware and software enforcing an access control policy between two networks. Typically, a firewall checks that requests are coming from, and responses are going to, apparently valid addresses. Some firewalls check the data content of selected protocols, but there are limits to what can be checked. There have been several embarrassingly public demonstrations of Web servers whose content has been replaced by derogatory pages, despite the presence of firewalls. Often, these hackers have succeeded because valid HTTP uniform resource locator (URL) requests to the Web server allowed software to be run that contained unintended security holes in it, such as permitting any data file to be read or written or even executing arbitrary binary code.

Therefore, it is necessary to secure the Web server against as many vulnerabilities as possible and to ensure that if the Web server is compromised, the attacker's access to data is limited. Hardening Web servers against attack has been the subject of several books, such as Practical Unix & Internet Security by Simson Garfinkel, Gene Spafford, and Alan Schwartz ^[2] so only a brief checklist is given here.

^[2] S. Garfinkel, G. Spafford, and A. Schwartz. Practical Unix & Internet Security , 3rd Edition. (Sebastopol, CA: O'Reilly & Associates, 2003).

• Disable all network services that do not need to be present; where possible, allow only HTTP and the gateway protocol.

• Check the Web server configuration files to allow access only to the required set of pages.

• Delete any CGI-BIN and other executable programs that are not required; if they are not present, they cannot be run.

• Use Java servlets and/or JSP applications in place of CGI programs.

• Restrict the privileges of the Web server program, if possible. On UNIX, the Web server can be run as a normal user with restricted access rights.

These guidelines also apply to any gateway software. Ensure that it does not provide access to resources that are not required for it to run. In particular, do not depend on the client to validate requests. Assume that a hacker has constructed a modified client that can generate any possible request, including a wide variety of invalid requests. For example, for a 3270 gateway, do not assume that the client will request connection to only a limited set of hosts. Configure the gateway so that the minimal number of hosts have connections available. No other host names must be visible. For database access and transaction processing, make sure that the gateway allows no more than the set of permitted requests and that its authorizations are limited to a minimal set.