5.9. Providing Security
Use of the server’s built-in capabilities to manage security is discussed in Chapter 7 (Declarative Security). This section summarizes the web.xml elements that relate to this topic.
Designating the Authorization Method
You use the login-config element to specify how the server should authorize users who attempt to access protected pages. It contains three possible subelements: auth-method, realm-name, and form-login-config. The login-config element should appear near the end of the web.xml deployment descriptor, immediately after the security-constraint element discussed in the next subsection. For complete details on the ordering of elements within web.xml, see Section 5.2. For details and examples on the use of the login-config element, see Chapter 7 (Declarative Security).
auth-method
This subelement of login-config lists the specific authentication mechanism that the server should use. Legal values are BASIC, DIGEST, FORM, and CLIENT-CERT. Servers are only required to support BASIC and FORM.
BASIC specifies that standard HTTP authentication should be used, in which the server checks for an Authorization header, returning a 401 status code and a WWW-Authenticate header if the header is missing. This causes the client to pop up a dialog box that is used to populate the Authorization header. Details of this process are discussed in Section 7.3 (BASIC Authentication). Note that this mechanism provides little or no security against attackers who are snooping on the Internet connection (e.g., by running a packet sniffer on the client’s subnet) since the username and password are sent with the easily reversible base64 encoding. All compliant servers are required to support BASIC authentication.
DIGEST indicates that the client should transmit the username and password using the encrypted Digest Authentication form. This provides more security against network intercepts than does BASIC authentication, but the encryption can be reversed more easily than the method used in SSL (HTTPS). The point is somewhat moot, however, since few browsers currently support Digest Authentication, and consequently servlet containers are not required to support it.
FORM specifies that the server should check for a reserved session cookie and should redirect users who do not have it to a designated login page. That page should contain a normal HTML form to gather the username and password. After logging in, users are tracked by means of the reserved session-level cookie. Although in and of itself, FORM authentication is no more secure against network snooping than is BASIC authentication, additional protection such as SSL or network-level security (e.g., IPSEC or VPN) can be layered on top if necessary. All compliant servers are required to support FORM authentication.
CLIENT-CERT stipulates that the server must use HTTPS (HTTP over SSL) and authenticate users by means of their Public Key Certificate. This provides strong security against network intercept, but only J2EE-compliant servers are required to support it.
realm-name
This element applies only when the auth-method is BASIC. It designates the name of the security realm that is used by the browser in the title of the dialog box and as part of the Authorization header.
form-login-config
This element applies only when the auth-method is FORM. It designates two pages: the page that contains the HTML form that collects the username and password (by means of the form-login-page subelement), and the page that should be used to indicate failed authentication (by means of the form-error-page subelement). As discussed in Chapter 7, the HTML form given by the form-login-page must have an ACTION attribute of j_security_check, a username textfield named j_username, and a password field named j_password.
For example, Listing 5.19 instructs the server to use form-based authentication. A page named login.jsp in the top-level directory of the Web app should collect the username and password, and failed login attempts should be reported by a page named login-error.jsp in the same directory.
Listing 5.19. web.xml (Excerpt showing login-config)
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<security-constraint>...</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- ... -->
</web-app> |
Restricting Access to Web Resources
So, you can tell the server which authentication method to use. “Big deal,” you say, “that’s not much use unless I can designate the URLs that ought to be protected.” Right. Designating these URLs and describing the protection they should have is the purpose of the security-constraint element. This element should come immediately before login-config in web.xml. It contains four possible subelements: web-resource-collection, auth-constraint, user-data-constraint, and display-name. Each of these is described in the following subsections.
web-resource-collection
This element identifies the resources that should be protected. All security-constraint elements must contain at least one web-resource-collection entry. This element consists of a web-resource-name element that gives an arbitrary identifying name, a url-pattern element that identifies the URLs that should be protected, an optional http-method element that designates the HTTP commands to which the protection applies (GET, POST, etc.; the default is all methods), and an optional description element that provides documentation. For example, the following web-resource-collection entry (within a security-constraint element) designates that all documents in the proprietary directory of the Web application should be protected.
<security-constraint>
<web-resource-collection>
<web-resource-name>Proprietary</web-resource-name>
<url-pattern>/proprietary/*</url-pattern>
</web-resource-collection>
<!-- ... -->
</security-constraint> It is important to note that the url-pattern applies only to clients that access the resources directly. In particular, it does not apply to pages that are accessed through the MVC architecture with a RequestDispatcher or by the similar means of jsp:forward. This asymmetry is good if used properly. For example, with the MVC architecture a servlet looks up data, places it in beans, and forwards the request to a JSP page that extracts the data from the beans and displays it (see Section 3.8). You want to ensure that the JSP page is never accessed directly but instead is accessed only through the servlet that sets up the beans the page will use. The url-pattern and auth-constraint (see next subsection) elements can provide this guarantee by declaring that no user is permitted direct access to the JSP page. But, this asymmetric behavior can catch developers off guard and allow them to accidentally provide unrestricted access to resources that should be protected.
|
auth-constraint
Whereas the web-resource-collection element designates which URLs should be protected, the auth-constraint element designates which users should have access to protected resources. It should contain one or more role-name elements identifying the class of users that have access and, optionally, a description element describing the role. For instance, the following part of the security-constraint element in web.xml states that only users who are designated as either Administrators or Big Kahunas (or both) should have access to the designated resource.
<security-constraint>
<web-resource-collection>...</web-resource-collection>
<auth-constraint>
<role-name>administrator</role-name>
<role-name>kahuna</role-name>
</auth-constraint>
</security-constraint> It is important to realize that this is the point at which the portable portion of the process ends. How a server determines which users are in which roles and how it stores user passwords is completely system dependent. See Section 7.1 (Form-Based Authentication) for information on the approaches used by Tomcat, JRun, and ServletExec.
For example, Tomcat uses install_dir/conf/tomcat-users.xml to associate usernames with role names and passwords, as in the example below that designates users joe (with password bigshot) and jane (with password enaj) as belonging to the administrator and/or kahuna roles.
<tomcat-users>
<user name="joe"
password="bigshot" roles="administrator,kahuna" />
<user name="jane"
password="enaj" roles="kahuna" />
<!-- ... -->
</tomcat-users>
|
user-data-constraint
This optional element indicates which transport-level protections should be used when the associated resource is accessed. It must contain a transport-guarantee subelement (with legal values NONE, INTEGRAL, or CONFIDENTIAL) and may optionally contain a description element. A value of NONE (the default) for transport-guarantee puts no restrictions on the commu-nication protocol used. A value of INTEGRAL means that the communication must be of a variety that prevents data from being changed in transit without detection. A value of CONFIDENTIAL means that the data must be transmitted in a way that prevents anyone who intercepts it from reading it. Although in principle (and in future HTTP versions) there may be a distinction between INTEGRAL and CONFIDENTIAL, in current practice they both simply mandate the use of SSL. For example, the following instructs the server to only permit HTTPS connections to the associated resource:
<security-constraint>
<!-- ... -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint> display-name
This rarely used subelement of security-constraint gives a name to the security constraint entry that might be used by a GUI tool.
Assigning Role Names
Up to this point, the discussion has focused on security that was completely managed by the container (server). Servlets and JSP pages, however, can also manage their own security. For details, see Chapter 8 (Programmatic Security).
For example, the container might let users from either the bigwig or bigcheese role access a page showing executive perks but permit only the bigwig users to modify the page’s parameters. One common way to accomplish this more fine-grained control is to call the isUserInRole method of HttpServletRequest and modify access accordingly (for an example, see Section 8.2).
The security-role-ref subelement of servlet provides an alias for a security role name that appears in the server-specific password file. For instance, suppose a servlet was written to call request.isUserInRole("boss") but is then used in a server whose password file calls the role manager instead of boss. The following would permit the servlet to use either name.
<servlet>
<!-- ... -->
<security-role-ref>
<role-name>boss</role-name> <!-- New alias -->
<role-link>manager</role-link> <!-- Real name -->
</security-role-ref>
</servlet> You can also use a security-role element within web-app to provide a global list of all security roles that will appear in the role-name elements. Declaring the roles separately could make it easier for advanced IDEs to manipulate security information.