Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

J2EE security architects are frequently faced with questions related to network topology design options and strategies for deploying J2EE applications in a production DMZ environment. The network design defines the security of the J2EE application deployment in a DMZ environment by the way it addresses architectural capabilities such as availability, reliability, scalability, manageability, and performance. In particular, these capabilities are greatly influenced by the network environment and characteristics of deployed J2EE components such as JSP/Servlets and EJBs. The key characteristics are as follows:

Stateless/stateful transactions: The availability and scalability characteristics are determined by considering the nature of transactions between the client and server. If the nature of transactions are idempotent (that is, stateless, where the order of transactions is not dependent on any transaction), then the availability strategies are trivial. If the transactions between the client and server mandate a state has to be maintained between the individual client HTTP requests and server HTTP responses, then the production deployment architecture must provide high-availability strategies that include session failover and fault-tolerance. This adds a bit more complexity as it requires a state-aware multilayer switch with load-balancing capabilities and the ability to switch based on session IDs and cookies.

Partitioning: The J2EE application itself might make better use of resources by segregating the Web tier from applications. If an application makes use of heavy static-content Web pages and then JSP/Servlets and EJBs for business logic, it might make sense to use Web servers to render static content and then use application servers for dynamic content that requires business-logic processing.

Security level: Separating the Web tier, Business tier, and Integration tier with a firewall creates a more secure solution. The potential drawbacks include hardware and software costs, increased communication latencies between servlet and EJB communication, and increased manageability costs.

Failover and fault-tolerance: The J2EE application server failover and fault-tolerance capabilities play a vital role in the infrastructure configuration. The failover capabilities forward requests from failed instances to available server instances without interrupting the service to the client. Fault-tolerance insulates applications from failures and without other coexisting application server instances.

Performance: In some cases, architects are willing to forego tight security advantages for increased performance. For example, the firewall between the Web tier, the Business tier, and the Integration tier might be considered as overkill because the incoming traffic is already firewalled in front of the Web tier.

Scalability: J2EE applications can be partitioned and deployed based on two scalability models. In a horizontally scaled environment, many small separate server infrastructures are utilized for multiple instances of Web servers and application servers to cater to the different tiers. In a vertically scaled environment, a few monolithic systems (large-scale servers) are able to support many instances of Web servers and application servers.

Manageability: In general, the fewer the number of servers, the lower the total cost of operation (TCO).

Designing for Security with Horizontal Scalability

Figure 5-8 represents a logical network architecture (horizontally scaled) showing a horizontally partitioned J2EE application as Web-tier (JSP/Servlets), Application-tier (EJB components), and Back-end resources. The horizontal scalability is achieved by adding servers to run multiple instances of Web servers and application servers. The Web-server tier and the applications tier are separated with a firewall. This enhances the security, because the traffic between the Web server and the application servers is required to pass through the firewall. This may increase the reliability, availability, and performance of the overall infrastructure, because it depends on the load-balancing and nature of transactions. Horizontal scalability decreases the manageability because it increases the cost of operations manageability. A single point of failure will not lead to an overall system failure. This architectural model is usually not suitable for applications that have relatively intensive servlet-to-EJB communications and back-end transactions. Another potential disadvantage includes increased latency between Web-tier and application-tier communication.

To decouple the Web tier from applications, the Web server is configured with a reverse-proxy, which receives the HTTP requests from a client on the incoming network side and then opens another socket connection on the application server side to perform business application processing. This architectural model is suitable for applications that have relatively intensive servlet-to-EJB communications and less stringent security requirements.

Designing for Security with Vertical Scalability

Figure 5-9 represents a logical network architecture (vertically scaled) showing a partitioned J2EE application as Web-tier (JSP/Servlets), Application-tier (EJB components), and Back-end resources. The vertical scalability is achieved by adding capacity (memory, CPUs, and so forth) to existing servers without making any system infrastructure changes. Vertical scalability increases manageability and reduces the cost of manageability. A single point of failure at the server infrastructure may likely lead to an overall system failure. To overcome such failures, a high-availability (HA) cluster configuration becomes mandatory. This means that all the processes and the configuration associated with the Web servers and applications must be up and active in both primary and secondary servers of the HA cluster. The HA cluster provides resilience for the Web server and application-server infrastructure in the event of local hardware and software failures.

To decouple Web tier with applications, the Web server is configured with a reverse-proxy, which receives the HTTP requests from a client on the incoming network side and then forwards the request to the application server side to perform business application processing.