|[ Team LiB ]|
HTTP has a built-in authentication protocol. When you log in to a page that requires authentication, the Web server first sends back a message telling the browser to send authentication information. The browser then prompts you for a username and password to send to the server. After the browser sends the username and password (assuming they are correct), the Web server displays the requested page. The browser holds on to the authentication information in case the Web server asks for it again.
To set up BASIC authentication for a Web application, you must add several new tags to your web.xml file. Listing 23.2 shows a basic web.xml file that uses authentication.
<?xml version="1.0" encoding="ISO-8859-1"?> <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4"> <display-name>authtest</display-name> <description>A test of authentication</description> <security-constraint> <web-resource-collection> <web-resource-name>SecureTest</web-resource-name> <url-pattern>/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <user-data-constraint> <description>SSL not required</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> <auth-constraint> <description>Let only managers use this app</description> <role-name>manager</role-name> </auth-constraint> </security-constraint> <security-role> <description>The role of manager is one that can use our application. </description> <role-name>manager</role-name> </security-role> <login-config> <auth-method>BASIC</auth-method> </login-config> </web-app>
The main tags that have been added to the basic deployment descriptor are <security-constraint>, <login-config>, and <security-role>.
The <security-constraint> Tag
The <security-constraint> tag tells the servlet engine what security requirements your application has. You can have more than one security constraint if necessary. Within the security constraint, you must specify a Web resource collection with the <web-resource-collection> tag.
A Web resource collection is a collection of URL patterns to which the security constraint applies. For instance, you might want to restrict only a single directory in your application. The <url-pattern> tag in your resource collection would then contain a pattern matching the directory you want to restrict. The pattern /* in Listing 23.1 means that the security constraint applies to all URLs in the application's directory. The <web-resource-name> tag specifies the name for the Web resource collection. There is no connection between the name and any of the URLs within it. The name serves little purpose but can be useful for various development and configuration tools.
The other tag you find in the Web resource collection is the <http-method> tag. This specifies which HTTP methods require authentication. If you do not specify an HTTP method, the security applies to all HTTP methods. You might, for example, want to perform authentication for an HTTP POST but not for a GET. You might also want to perform different kinds of authentication for GET and POST. In the latter case, you specify two separate security constraints, one with an HTTP method of GET and the other with an HTTP method of POST. You can also use authentication with other HTTP methods such as PUT and DELETE.
The <user-data-constraint> tag tells the servlet engine what kind of data security your application needs. You can include a <description> tag to describe the constraint, but it is optional. The <transport-guarantee> tag indicates the kind of transport-level data security your application needs. The value for the <transport-guarantee> tag can be one of three values:
The <auth-constraint> tag enables you to specify the various roles to which this security constraint applies. The <role-name> tag enables you to specify a specific role. You can include multiple <role-name> tags within a single <auth-constraint> tag.
The <login-config> Tag
The <login-config> tag enables you to control the type of authentication you want the servlet engine and browser to perform. You specify the type of authentication through the <auth-method> tag. The servlet specification supports four kinds of authentication methods:
For BASIC authentication, you can specify a realm name using the <realm-name> tag. The realms help organize various sections of a Web site that might need authentication. By grouping applications into separate realms, you can require the user to log in to each application. The realm name isn't configured anywhere other than in the <realm-name> tag, so you don't need to worry about setting up different realms. A realm is basically a grouping of usernames and passwords. You can have multiple sets of users, each belonging to a different realm. For example, you might have a set of personnel Web applications with users belonging to a "manager" realm. Likewise, you might have an administration Web application with users that belong to an "admin" realm. In addition to usernames and passwords, you can define various roles for users. You can restrict parts of a Web application based on the role of a user (a user might belong to a "power-user" role or a "sysadmin" role). By granting access based on a role rather than an individual user, you can grant and revoke privileges to whole sets of users with a single operation.
The <security-role> Tag
The <security-role> identifies the roles that participate in an application. In this simple example, we've defined only onemanager. More-sophisticated applications will have several. It's important to note that the container is responsible for associating users and roles. As mentioned earlier, that means that you have to edit tomcat-users.xml, which is located off of Tomcat's home directory in conf. The format of that file is self-explanatory.
|[ Team LiB ]|