15.1 Understanding the Environment

 <  Day Day Up  >  

In order to architect a J2EE-compliant hosting environment ”in other words, a Web application server ”it is important to understand the environment in which it will be deployed. Such an environment may have to support a set of authentication mechanisms that generate credentials to represent an identity, user registries that contain the user account information, authorization policies that need to be managed, authorization providers that should be accommodated to make access decisions, and secure communication between processes. Understanding a secure end-to-end request flow helps in making sense of these requirements.

Figure 15.1 depicts the end-to-end flow of a J2EE request and shows the security aspects of such a flow (see also Section 3.12 on page 97). A request from an HTTP client typically gets routed through an HTTP listener and dispatcher, such as a Web server, to an appropriate Web container that handles the incoming request. A secure request will typically be submitted over an HTTP connection over the SSL protocol ”an HTTPS request. In these cases, the Web server will act as the SSL termination point. The Web server can either be a stand-alone unit or a component in the Web container listening to HTTP requests . In the case of a stand-alone Web server, a request to a J2EE resource, such as a servlet, will be routed to an appropriate Web container.

Figure 15.1. End-to-End Security Request Flow

graphics/15fig01.gif

Based on servlet matching rules, the Web container will process the request and associate a Web application with the request. The user will be authenticated based on the URL pattern and the protection policy of the URI defined in that Web application. After successful authentication, access to the resource will be allowed if the user submitting the request is granted one of the required roles associated with the URI. The Web container is then responsible for setting the security context for proceeding with the execution of the servlet. The Web container is also responsible for satisfying the requirements of programmatic APIs, such as the getUserPrincipal() and the isUserInRole() servlet methods in the javax.servlet.http.HttpServletRequest interface.

When the servlet invokes an enterprise bean, the request is forwarded to the EJB container, possibly in a different Web application server. In this case, the Web container and the EJB container should initiate a secure session to establish a trust relationship between them. As part of the secure association, the communication link between the containers should be over a secure channel: for example, an SSL session. If this request is over IIOP, the CSIv2 protocol can be used to establish the secure association between the containers. Once such a session is established, the identity of the requester ”or the resultant identity based on the delegation policy ”is forwarded to the EJB container.

When a request for an EJB invocation arrives at an EJB container, the container is responsible for validating the user identity propagated by the Web container. Once the credential is validated and a security context is established, authorization to the EJB request will be enforced by the container, based on the authorization policies associated with the enterprise bean. As in the case of a Web application, the security context will be maintained so that the container can satisfy the requirements of programmatic APIs, such as the getCallerPrincipal() and the isCallerInRole() methods in the javax.ejb.EJBContext interface.

Sometimes, business logic implemented as an enterprise bean needs to access non-J2EE applications or data stores. In such a case, the Connection Manager implementation of the container must adhere to the Java connector framework and facilitate the mapping of the requesting identity to an identity, or credential, that can be used by the target resource adapter.

The end-to-end security scenario discussed in this section provides some context to help J2EE Container Providers to implement the runtime. The following sections illustrate an approach to building a WAS, using Java-based security technologies where appropriate.

 <  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