We now introduce an architecture overview for the component technologies of Java 2 Enterprise Edition (J2EE) used in a typical enterprise web application. The discussion is focused on the technologies used across the various tiers, namely the client tier,
presentation tier, business logic tier, and the database tier. The discussion in this section presents the architectural overview of some of the J2EE technologies that will be
instrumental for further discussion the support for core security services.
The first thing to understand about J2EE which plays a very important from a security standpoint is that J2EE is a specification for an enterprise platform and services. A variety of vendors implement the various parts of the J2EE specification. For instance, Jakarta Tomcat implements the J2EE web container specification and JBoss implements the EJB container specification. The point is that since a wide variety of vendors provide implementation to the J2EE specification, many application level vulnerabilities and compensating controls might in fact be specific to the independent software vendor (ISV) providing the implementation. For this reason, the discussion of security in the context of J2EE will be vendor specific to some extent. Additionally, while J2EE specification mandates certain solutions to address the core security services, the implementation of these solutions will be vendor specific. While we try to keep the discussion generic whenever possible, when implementation level detail needs to be considered, we will be referring to the BEA Weblogic implementation of the J2EE application server and the associated services.
Sun Microsystems offers the following description of the J2EE platform: “The J2EE platform represents a single standard for implementing and deploying enterprise
applications. The J2EE platform has been designed through an open process, engaging a range of enterprise computing vendors, to ensure that it meets the widest possible range of enterprise application requirements. As a result, the J2EE platform addresses the core issues that impede organizations' efforts to maintain a competitive pace in the
information economy” [23].
J2EE provides a distributed multi-tier application model where individual components can be distributed across different machines and heterogeneous platforms. The client tier of the J2EE enterprise web application is comprised of thin clients (user browsers) that can be located inside or outside the corporate firewall. A web application can also have other types of clients at the client tier, but we focus the discussion in this paper on thin clients. The application server resides on the middle tier of the J2EE enterprise web application and is compromised of the Web and EJB containers that provide services to the client tier. Web container handles the presentation layer of the application via Servlet and JSP technologies. An EJB container provides lifecycle management support for
transaction aware business components that implement all of the business logic for the application. In enterprise deployments those two containers would rarely be on the same machine. In fact, the components within each of these containers are likely to be
distributed across multiple machines if for no other reason than for fault tolerance and load balancing purposes. The Enterprise Information Systems (EIS) tier is the database or persistence tier of the J2EE based enterprise web application abstracting standardized access via API to variety of data stores. Figure below summarizes a set of technologies used across each of the tiers of the J2EE application.
Figure 12: Overview of J2EE Web Application Architecture [23] The important point to understand about J2EE containers is that they are standardized runtime environments which provide a variety of services to the components that are deployed inside them. Regardless of the vendor implementing the J2EE container, developers writing J2EE components can always rely on certain services to be provided. J2EE application server developers may and usually do choose to make additional
features and services available to component developers, but component developers are always guaranteed to have available the set of services mandated by the J2EE
specification. Thus if component developers use only vendor independent features available to them by the J2EE containers, the constructed components are guaranteed to work on different implementations of the J2EE application server. Some common services that J2EE containers provide to components include APIs that provide access to database (JDBC), transaction (JTA), naming and directory (JNDI), and messaging services (JMS). The J2EE platform also provides technologies that enable
communication between collaborating objects hosted by different servers (RMI). Among other services, security related services are provided by the J2EE containers for the component developers to use. Some of those services are mandated by the J2EE
specification and others are application server vendor specific. Figure below presents yet another view of the J2EE architecture with specific emphasis on the various kinds of supported services and the different types of application clients.
Figure 13: J2EE Components, Containers and Services [23] The diagram below illustrates the multi-tiered deployment model for a web based
enterprise J2EE application. You will notice the each of the tiers lists an associated set of technologies. Client tier can display HTML and XML pages and communicates with the web tier via HTTP or HTTPS. The web tier uses servlet and JSP technologies for
presentation layer. Business logic tier (EJB tier) hosts all of the business logic for the application and may make use of container provided services such as the Java Messaging Service (JMS), Java Transaction API (JTA), Java Database Connectivity (JDBC), etc. The EIS tier hosts the databases for the enterprise web application. J2EE security discussion in this paper will focus on this kind of four-tiered deployment model of the web based enterprise application built with J2EE.
It is also important to mention that the data flow in a typical J2EE enterprise web application follows the Model View Controller (MVC) architecture. This architecture attempts to uncouple the business functionality, control logic and presentation code. A model represents application data and business logic dictating access and changes to the data. A controller defines application behavior by ensuring that user actions result in proper model changes. A view is responsible for presenting the content of a model to the user. Understanding of the MVC is very important from the security perspective. Figure below illustrates the inner workings of MVC.
Figure 15: J2EE Model View Controller Architecture [23]
Much can be said about J2EE, but the goal of this section was only to provide high level architectural information required for subsequent discussion. A variety of additional information will be provided on J2EE as it becomes necessary. We now move on to look at the way that the J2EE specification addresses the core security services.