6.1 Planning a Secure-Component System

 <  Day Day Up  >  

Identifying the components that need to be secured is an important first step in designing a secure environment. Next, mechanisms that can be used to secure those components need to be identified. In practice, it is then necessary to understand which mechanisms are to be put together to secure the components , thus giving rise to a secure deployment scenario.

In a typical three- tier distributed-computing environment, such as the one represented in Figure 6.1, the presentation logic front ends the business logic. The business-logic layer hosts business applications, interacts with the data tier, and computes the results that will be delivered to the presentation-logic layer. Typically, security sensitivity increases from the first layer toward the last. Such partitioning into zones helps define the security requirements for the environment and the design of the topology to host the components.

Figure 6.1. Typical Three-Tier Distributed-Computing Environment

graphics/06fig01.gif

In a J2EE environment, the three-tier computing model can be extended to reflect a four-tier model, in which servlets and JSP files form the presentation layer, enterprise beans provide the business-logic abstraction, and the data is stored in the data source layer connected through resource adapters. This four-tier model is depicted in Figure 6.2.

Figure 6.2. J2EE Four-Tier Computing Model

graphics/06fig02.gif

The protocols of communications indicated in Figure 6.2 are as follows .

  1. Typically, the client- and server-side presentation layers communicate with each other using HTTP. When confidential information is involved, HTTP can be encrypted using the SSL protocol. HTTP over SSL is known as HTTPS.

  2. The server-side presentation and business-logic layer communicate using Java RMI-IIOP.

  3. The server-side business-logic and data-logic layers communicate through a Java connector, such as JDBC.

6.1.1 Client Access

Access to an enterprise application is achieved through a variety of client applications. In the context of J2EE, the most common access is through HTTP or IIOP clients. Increasingly, other types of clients are including messaging clients and Web Services clients. The security model of an end-to-end flow must include the capabilities of the end client. In the context of HTTP, client access is over HTTPS routed through a firewall. In the case of IIOP thick clients , [1] security is enforced through the Common Secure Interoperability Version 2 protocol.

[1] Clients become thicker as they use increasing bandwidth and processor power. They become thinner as their transmission media decreases bandwidth and portability of devices decreases processing power. Typically, with thin-client computing, the bulk of the processing is not done at the mobile-client level, leaving this task to faster, more powerful controllers.

6.1.2 Presentation Layer

In discussing the presentation layer, we have to distinguish the presentation of static content from the presentation of dynamic content.

6.1.2.1 Static Content

When businesses initially connected to the Internet, the Internet was used primarily to share information that was considered public in nature. Such information was usually uploaded at predetermined intervals to the Web server and hence was considered to be static information. Because the information was public, restricting viewing access was not necessary. However, it was important to prevent unauthorized modification of that information. For example, if anyone were allowed to make modifications to a company's mission statement, it could be distorted to affect the company's business. Therefore, although information may be intended to be public and anyone can read it, steps should be taken to ensure that modification and deletion are restricted.

6.1.2.2 Dynamic Content

Dynamic Web content is used to tailor an individual's interactions with a Web site and provide users with more interactive information. Dynamic content may be rendered in various forms, including static HTML files or dynamic JSP files rendered using Java servlets in a J2EE environment. Those servlets may invoke business-logic applications hosted in a back-end tier to access business data, so that the data can be presented to the end user .

Depending on the design of such applications, it is possible that servlets go directly to the data source without introducing another layer of abstraction through enterprise beans. For example, servlets may use JDBC to access data in the back end directly, without necessarily encapsulating the business logic in an enterpise bean.

Even though servlets can perform such data access directly through JDBC calls, it is a recommended practice within J2EE environments to abstract out data access by using either enterprise beans or resource adapters, thereby providing a level of separation between the presentation layer and the business-logic layer. Because the presentation layer typically front ends access to the business logic, the presentation layer becomes a first important layer of defense in the access to business-critical data. Protecting servlets and JSP files thus becomes very important. Whether they are protected by a secure reverse proxy server that sits in front of the WAS and/or by the WAS itself depends on the environment topology and the corporate security policy and architecture.

6.1.3 Business Logic

EJB technology provides infrastructure for building business applications. These applications are accessible over the Internet or the intranet and can also be accessed through a variety of clients and client applications. Business-layer components provide the isolation of the presentation layer from the complexity of business logic: back-end resource adapters, connections, and legacy applications. This isolation aids in the design of deployment topologies by clearly delineating the requirements for authentication and authorization.

Connection from the business-logic layer to the back-end legacy applications is hidden from clients accessing the business logic. The connections between the business logic and the back-end applications are typically managed through Java connectors (see Section 3.4 on page 61). Security semantics of connecting to legacy applications are handled through the Java Connector Architecture (JCA), which provides the necessary adapters to those non-J2EE systems.

6.1.4 Resource Adapters and Legacy Applications

Many enterprise environments consist of applications that form the basis of their information technology infrastructure. These applications, known as legacy applications , are customized for enterprises and have been in use for a long time. In fact, these applications form the backbone of enterprise information systems and can manage such enterprise systems as banking-account, resource-planning and management, corporate-employee, human-resources, manufacturing-workflow, and inventory-control information systems. Legacy applications have helped streamline automated processes and work-flow systems.

J2EE defines a standard for accessing these data stores and legacy applications through the JCA. Though hidden from end-client applications, the business logic needs to be aware of the resource adapters used. In the case of bean-managed persistence, the enterprise bean is responsible for obtaining the information from the data store and applying the business logic. This is not necessary in the case of container-managed persistence, in which the EJB container transparently and implicitly manages the persistent state of the enterprise bean, and the enterprise bean developer does not need to code any database-access functions within the enterprise bean class methods (see Section 3.2.1 on page 58). The back-end databases and enterprise applications and systems can be protected by using their own proprietary security models.

Depending on the sensitivity of the data or legacy-application topology, access to the data store and applications is protected in a variety of ways.

  • At one end of the spectrum is a privileged identity that is allowed access to all the sensitive parts of the EIS. Therefore, once enterprise beans are securely accessed, they are assumed to be allowed access to the data store or other non-J2EE applications under that privileged identity.

  • At the other end of the spectrum is the requirement to propagate the identity of the caller, starting at the client, all the way to the back end where the data store or legacy application, which makes its own authorization decisions based on the caller's identity, resides.

By layering the business and presentation logic, it is possible to architect the system topology in a way that J2EE and non-J2EE system security can be carefully and deliberately considered.

 <  Day Day Up  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net