| The security behavior of a J2EE environment may be better understood by examining what happens in a simple application with a web client, JSP page user interface, and enterprise bean business logic. We include here a descriptive example; this example is not meant to specify requirements. In this example, the web client relies on the web server to act as its authentication proxy by collecting user authentication data from the client and using it to establish an authenticated session. - Step 1. Initial Request
The web client requests the main application URL, shown in Figure J2EE.3-1.
Figure J2EE.3-1. Initial Request  Since this client has not yet authenticated itself to the application environment, the server responsible for delivering the web portion of the application (hereafter referred to as "web server") detects this and invokes the appropriate authentication mechanism for this resource.
- Step 2. Initial Authentication
The web server returns a form that the web client uses to collect authentication data (e.g., username and password) from the user. The web client forwards the authentication data to the web server, where it is validated by the web server, as shown in Figure J2EE.3-2.
Figure J2EE.3-2. Initial Authentication  This validation mechanism could be local to the server, or it could leverage the underlying security services. The web server then sets a credential for the user.
- Step 3. URL Authorization
The web server determines if the user whose identity is captured in the credential is authorized to access the resource represented by the URL. The web server performs the authorization decision by consulting the security policy (derived from the deployment descriptor) associated with the web resource to determine the security roles that are permitted access to the resource. The web container then tests the user's credentials against each role to determine if it can map the user to the role. Figure J2EE.3-3 shows this process.
Figure J2EE.3-3. URL Authorization  The evaluation stops with an "is authorized" outcome on the first role that the web container is able to map the user to. A "not authorized" outcome is reached if the web container is unable to map the user to any of the permitted roles.
- Step 4. Fulfilling the Original Request
If the user is authorized, the web server returns the result of the original URL request, as shown in Figure J2EE.3-4.
Figure J2EE.3-4. Fulfilling the Original Request  In this case, the response of a JSP page is returned. Next, the user performs some action (perhaps posting form data) that needs to be handled by the business logic component of the application.
- Step 5. Invoking Enterprise Bean Business Methods
When the JSP page performs the remote method call to the enterprise bean, the user's credential is used to establish (as shown in Figure J2EE.3-5) a secure association between the JSP page and the enterprise bean. The association is implemented as two related security contexts, one in the web server and one in the EJB container.
Figure J2EE.3-5. Invoking an Enterprise Bean Business Method  The EJB container is responsible for enforcing access control on the enterprise bean method; it does so by consulting the security policy (derived from the deployment descriptor) associated with the enterprise bean to determine the security roles that are permitted access to the method. Then for each role, the EJB container will use the security context associated with the call to determine if it can map the caller to the role. The evaluation stops with an "is authorized" outcome on the first role that the EJB container is able to map to the caller. A "not authorized" outcome is reached if the container is unable to map the caller to any of the permitted roles and results in an exception being thrown by the container, and propagated back to the caller (in this case the JSP page). If the call "is authorized," the container dispatches control to the enterprise bean method, which then returns a result to the caller. The platform provides two sets of methods for use by security aware applications: the EJBContext methods isCallerInRole and getCallerPrincipal available to enterprise beans through the EJB container, and the HttpServletRequest methods isUserInRole and getUserPrincipal available to servlets and JSP pages through the web container. When an enterprise bean calls the isCallerInRole method, the enterprise bean container determines if the caller (as represented by the security context) is in the specified role. When an enterprise bean calls the getCallerPrincipal method, the enterprise bean container returns the principal associated with the security context. The web container APIs behave similarly. |
