Security in Web Applications and Components

The Web security features of J2EE use the same model as the EJB security. Security is implemented using declarations in the deployment descriptor and programming in the Web pages. Authorization is enforced using roles and principals in the same manner as EJB security.

The key concepts for the Web security model are

• Single login— A client is only required to authenticate itself once to access all Web pages in the same realm. The Web server defines security realms, and the deployer decides to which realm each Web application belongs. Each realm can use a different authentication mechanism (effectively, a different collection of usernames).

• Spans multiple applications— An authenticated client should be able to use Web pages from different Web applications without having to login for each application.

• Associated with session— The security credentials must be associated with the servlet session, so that each servlet or JSP can access the credentials when required for programmatic authorization.

The J2EE Web security specifies requirements for client authentication as well as authorization for Web applications.

Web Authentication

The J2EE 1.3 specification does not explicitly specify a Web authentication mechanism, but uses the Servlet 2.3 specification that defines four mechanisms for authenticating users:

• Basic HTTP

• HTTP Digest

• Forms based

• HTTPS Client

The Servlet 2.3 specification can be found on the Sun Microsystems' web site at http://java.sun.com/products/servlet/download.html.

Basic HTTP Authentication

The HTTP protocol defines a simple authentication system where the Web server can request the client to supply a username and password. The Web client obtains the username and password of the user and returns them to the Web server for authentication. The popular Web browsers display a simple login form for the user to provide authentication information.

The username and password are returned to the Web server using a simple encoding scheme. Basic HTTP authentication is simple and effective, but it does not provide confidentiality because the username and password are easily obtained by hackers that can monitor network traffic. In reality, hackers will find it almost impossible to monitor network traffic outside of their own organization. However, malicious company employees with the requisite knowledge and software will be able to monitor internal networks.

HTTP Digest Authentication

HTTP Digest authentication works in a similar manner to Basic HTTP authentication except that the username and password are returned in an encrypted form. The encrypted username and password are more secure against illicit monitoring of network traffic.

HTTP digest authentication is not required by the Servlet 2.3 specification because it is not widely supported by Web clients at the present time.

Forms-Based Authentication

J2EE Web applications can specify their own forms-based authentication. This is similar to basic HTTP authentication, but a form is supplied by the application when a user has to be authenticated. The application can supply an authentication form with the same look and feel as the other Web pages in the application, instead of using the simple form provided by a Web browser.

HTTPS Client Authentication

This is the most secure form of authentication because it requires the client to identify itself using a digital certificate. Client authentication is usually implemented by using SSL and is supported by the common Web browsers. This is a large subject area, and there is insufficient space for it to be covered in today's lesson.

Configuring J2EE RI Basic Authentication

To illustrate the basic features of J2EE Web security, you will need to configure the Web interface to the Agency case study to authenticate users. You will use basic HTTP authentication because it is the simplest mechanism to configure for your Web application.

Start up deploytool, open the agency.ear file in today's “examples” directory and select the Web application you developed on Day 13, “JavaServer Pages” and Day 14 (called web). Choose the Security tab and select Basic from the list of options in the User Authentication Method section on the form. Figure 15.12 shows the Basic authentication mechanism being selected from the list of choices.

The Settings button is used to configure additional features for each authentication method. The only configurable property for Basic HTTP authentication is the realm in which to authenticate the user. The J2EE RI only provides one realm, called default, for use with Basic HTTP authentication. Although the J2EE RI defines a second realm called certificate, but this is for use with HTTPS (SSL)-based client authentication.

Your changes have added a <login-config> security constraint to the DD entry for the Web application, as shown in Listing 15.8.

Listing 15.8. Web Authentication in the DD

1: <web-app>
2:   <display-name>Web</display-name>
3:   ...
4:   <login-config>
5:     <auth-method>BASIC</auth-method>
6:     <realm-name></realm-name>
7:   </login-config>
8:   ...
9: <web-app>

Defining the authentication mechanism does not force the client to authenticate itself for pages in the Web application. You will need to add declarative security constraints for the Web pages that have to be protected as discussed in the “Declarative Web Authorization” section later in this chapter. When the user accesses one of the protected pages, the server will use Basic HTTP authentication to obtain the username and password and validate these credentials against the default security realm.

Declarative Web Authorization

Authorized access to Web pages is based on the URL of the Web page. By default, all pages are unprotected, but the DD for a Web application can define security constraints to force a client to authenticate itself before accessing the protected pages.

Authorization is based on roles and constraints. A Web application defines the roles required to access different functionality within the application. One or more constraints can be defined to authorize access to an individual page or a group of pages based on the roles defined for the application.

As with EJB security roles, the deployer must map the role references used in the DD onto principals defined in the target authentication domain.

Configuring J2EE RI Declarative Web Security

Web application roles are defined in deploytool using the Roles page for the Web application. To contrast with the example of EJB security that identified applicants and customers as separate roles, the Web application will treat all potential applicants and customers as clients. You will configure two roles for your Web application, as shown in Table 15.6.

Figure 15.13 shows the configured roles for the Agency case study.

After the application roles have been defined, you can add one or more security constraints. A security constraint defines the following:

• A list of roles that are authorized by this constraint

• One or more Web resource collections that define the Web pages protected by this constraint

• A list of protected Web pages each defined by a URL pattern and the HTTP request names GET and POST

Constraints are applied to the Web application rather than an individual Web component. In deploytool, select the Web application (called web) and the Security tab (this page is shown in Figure 15.14 after you have made the changes discussed in the rest of this section).

Before adding any constraints, you must decide which parts of the Web application must be protected. The main portal page (agency.jsp) should be accessible to all users because this page is used to create new customer or applicant details. Existing customers also use this page to access their data.

Functionality for customers, jobs, and applicants should be protected so that only authenticated clients can use those pages. The administration page (admin.jsp) for maintaining skill and location lists should only be accessible to authenticated clients in the Administration role.

To enforce these restrictions, you will need two separate constraints for your Web application:

• One constraint to allow clients and administrators to access customer, job, and applicant functionality

• One constraint to allow administrators to maintain the skill and location lookup tables

On Day 13, you chose aliases for your Web pages to simplify the definition of the security constraints. All of the customer functionality uses aliases of the form /customer/…; similarly, applicant functionality is /applicant/…. This naming scheme can be used when applying authorization to Web pages.

The following steps will set up the first of these constraints:

You have had to protect the real Web page filenames as well as the page aliases because authorization is based on URL patterns and not the physical file location.

You may be wondering why you have protected the actual JSP page when the pages themselves always use the page alias. To answer that, you have to remember that the Web is not a secure environment. There are users who will try to break your security by examining HTTP requests and URLs in an attempt to detect logical naming patterns.

Seeing a URL pattern such as customer/advertise?customer=winston, hackers will try different customer names or variations on the Web address to bypass your security.

It only takes one determined hacker to find that the URL advertise.jsp?customer=winston works and your security mechanism has been circumvented unless you protect the individual JSP pages as well as the URL pattern customer/*.

Where security is concerned, it is better to err on the side of caution and protect everything rather than leave a small loophole for a hacker to exploit.

You must now add a second Resource Collection for protecting access to the applicant registration functionality. Create a new Resource Collection (call it Applicants) and protect the URL Pattern /applicant/* and the following JSP pages:

• register.jsp

• createApplicant.jsp

• deleteApplicant.jsp

• updateApplicant.jsp

The last constraint you need is to protect the administrative functionality on the admin.jsp page. Because this requires a different set of roles, you will need to

The last portion of the Security screen describes the options for the Network Security Requirements. There are three options available:

• none There are no network security requirements.

• integral The transfer of the data between server and client must guarantee that the data will not be changed.

• confidential The transfer of the data between server and client must guarantee that the data cannot be observed.

In practice, choosing an option other than none will usually necessitate the use of SSL. The default value of none will suffice during your study of J2EE security.

After you have defined all of these changes, the DD will have the <security-constraint> entries, as shown in Listing 15.9.

Listing 15.9. Web Security Constraints in the DD

 1: <web-app>
 2:   <display-name>Web</display-name>
 3:   ...
 4:   <security-constraint>
 5:     <web-resource-collection>
 6:       <web-resource-name>Administration</web-resource-name>
 7:       <url-pattern>/modifySkill.jsp</url-pattern>
 8:       <url-pattern>/createSkill.jsp</url-pattern>
 9:       <url-pattern>/updateLocation.jsp</url-pattern>
10:       <url-pattern>/admin.jsp</url-pattern>
11:       <url-pattern>/modifyLocation.jsp</url-pattern>
12:       <url-pattern>/updateSkill.jsp</url-pattern>
13:       <url-pattern>/admin/*</url-pattern>
14:       <url-pattern>/deleteSkill.jsp</url-pattern>
15:       <url-pattern>/deleteLocation.jsp</url-pattern>
16:       <url-pattern>/createLocation.jsp</url-pattern>
17:     </web-resource-collection>
18:     <auth-constraint>
19:       <role-name>Administrator</role-name>
20:     </auth-constraint>
21:     <user-data-constraint>
22:       <transport-guarantee>NONE</transport-guarantee>
23:     </user-data-constraint>
24:   </security-constraint>
25:   <security-constraint>
26:     <web-resource-collection>
27:       <web-resource-name>Customers</web-resource-name>
28:       <url-pattern>/updateCustomer.jsp</url-pattern>
29:       <url-pattern>/advertise.jsp</url-pattern>
30:       <url-pattern>/customer/*</url-pattern>
31:       <url-pattern>/updateJob.jsp</url-pattern>
32:       <url-pattern>/createJob.jsp</url-pattern>
33:       <url-pattern>/deleteJob.jsp</url-pattern>
34:       <url-pattern>/deleteCustomer.jsp</url-pattern>
35:       <url-pattern>/createCustomer.jsp</url-pattern>
36:     </web-resource-collection>
37:     <web-resource-collection>
38:       <web-resource-name>Applicants</web-resource-name>
39:       <url-pattern>/updateApplicant.jsp</url-pattern>
40:       <url-pattern>/applicant/*</url-pattern>
41:       <url-pattern>/register.jsp</url-pattern>
42:       <url-pattern>/createApplicant.jsp</url-pattern>
43:       <url-pattern>/deleteApplicant.jsp</url-pattern>
44:     </web-resource-collection>
45:     <auth-constraint>
46:       <role-name>Administrator</role-name>
47:       <role-name>Client</role-name>
48:     </auth-constraint>
49:     <user-data-constraint>
50:       <transport-guarantee>NONE</transport-guarantee>
51:     </user-data-constraint>
52:   </security-constraint>
53:   ...
54: </web-app>
						

You can now deploy the application with the declarative security enabled. After deploying your application, you can still access the main portal page http://localhost:8000/agency/agency without authentication. However, if you select a customer name such as winston from the list and get to the advertise page, you will be prompted to enter a username and password. This is the basic HTTP security authentication mechanism.

You must log in with the same name as the customer (winston) you selected from the list on the agency.jsp page. If you chose any other login name, the EJB programmatic security you added to the advertise Session bean will throw an exception because the customer name does not match your principal name.

In the next section, you will use programmatic Web security to remove the need for an existing customer or applicant to select his or her name from a list.

Programmatic Web Authorization

Web applications that are security aware use three methods in the HTTP request object to access the authenticated client's security information.:

• boolean HttpServletRequest.isUserInRole(String role) Returns true if the client is in the role passed as a parameter.

• Principal HttpServletRequest.getUserPrincipal() Returns a java.security.Principal object representing the client's principal. Unlike the EJBContext.getCallerPrincipal() method, this method can return null if the client has not been authenticated.

• String HttpServletRequest.getRemoteUser() Returns the principal name of the client or null if the client has not been authenticated.

Adding Programmatic Web Security to the Case Study

The Agency case study does not need any programmatic security additions. The component Session beans (advertise and register) ensure that authenticated clients can only access his or her own details. However, the user interface can be improved by making use of the principal information from the client authentication.

The Agency case study main page (agency.jsp) presents the user with a list of customers to select from and a small form for creating a new customer. There is no need for the user to be given a list of customers if an authentication mechanism is used. The user's login name can be used to the appropriate customer data. The customer section of the simplified form is shown in Listing 15.10.

Listing 15.10. Customer Options in agency.jsp

 1: <H2>Customers</H2>
 2: <FORM action=customer/advertise>
 3: Existing customer: <input type=submit value="Login">
 4: </FORM>
 5: <H3>New Customer</H3>
 6: <FORM action=customer/createCustomer>
 7: <TABLE>
 8: <TR>
 9:   <TD>Login:</TD>
10:   <TD><INPUT type=text name=login></TD>
11: </TR>
12: <TR>
13:   <TD>Name:</TD>
14:   <TD><INPUT type=text name=name></TD>
15: </TR>
16: <TR>
17:   <TD>Email:</TD>
18:   <TD><INPUT type=text name=email></TD>
19: </TR>
20: <TR>
21:   <TD colspan=2><INPUT type=submit value="Create Customer"></TD>
22: </TR>
23: </TABLE>
24: </FORM>
						

An existing customer simply clicks the Login button and the Web authentication form is displayed for the user to login. On successful login, the advertise.jsp page is dis-played, and this should obtain the current customer from the remote client principal name.

To allow an administrator to login as any user, the form tests the caller's role and, if the authenticated user is an administrator, obtains the customer name from the page parameter. Listing 15.11 shows the new section of code that obtains the customer name.

Listing 15.11. Customer Name Selection in advertise.jsp

 1: <%
 2:   String name = null;
 3:   if (request.isUserInRole("admin"))
 4:      name = request.getParameter("customer");
 5:   else
 6:      name = request.getRemoteUser();
 7: %>
 8: <agency:getCust login='<%=name%>'/>
 9: <H2>Customer details for: <jsp:getProperty name="cust" property="login"/></H2>
						

To support the isUserInRole() method, an entry must be added to the DD to map the role reference of admin onto the real role of Administrator. This is done on the Security page of the advertise Web application, as shown in Figure 15.15.

Role references are defined in the <servlet> entry in the <web-app> section of the DD. Listing 15.12 shows the admin role reference added to the DD.

Listing 15.12. Role Reference in Web Application DD

1: <servlet>
2:   <servlet-name>advertise</servlet-name>
3:   <display-name>advertise</display-name>
4:   <jsp-file>/advertise.jsp</jsp-file>
5:   <security-role-ref>
6:     <role-name>admin</role-name>
7:     <role-link>Administrator</role-link>
8:   </security-role-ref>
9: </servlet>
						

In Listing 15.11, if the client is in the admin role, the code still uses the request parameter customer for the customer name. This supports the requirement for an administrator to be able to modify customer details. The code to do this has been added to the admin.jsp file for today's work on the accompanying CD-ROM and is not shown here.

Web applications, like EJBs, can define security roles by using a specific role rather than using the client's ID. The Web application Security page is used to define the available security options.

You can now redeploy the Agency case study and test out the new Web interface. If you test the new changes and login as an applicant (such as romeo) rather than as a customer (such as winston) your JSP will fail because it cannot create the required advertise session EJB. This will prevent any output being returned to your browser, and a browser specific error message will inform you that the requested document has no data. Obviously, in a real application, you would detect the failure to create the Session EJB in the JSP page and report a suitable error to the user.

Using Secure Web Authentication Schemes

The basic HTTP authentication mechanism is suitable for development and testing, but many commercial applications require more “secure” authentication schemes. As discussed earlier, the J2EE Servlet specification requires the server to support HTTPS certificate-based authentication for secure applications by using confidential data.

Because you will never use J2EE RI as a commercial server, learning how to make it secure is not a useful exercise; you have many other features of J2EE to learn in the remaining six days.

If understanding and using HTTPS and SSL is necessary for your understanding of J2EE, this is best done with your commercial Web server. Read the documentation and tutorials with your Web server and give it a go. The basic understanding of security you have gained from today's work will stand you in good stead when implementing certificate-based security.