Web-Tier Security

Security in a Web application is configured in the Web application deployment descriptor using deploytool. When the settings are entered in deploytool, they are saved to the deployment descriptor contained in the WAR. To view the generated deployment descriptor, choose Descriptor Viewer from deploytool's Tools menu. For more information on deployment descriptors, see Chapter 3.

After a WAR is created, select the Security tabbed pane to configure its security elements. See Setting Security Requirements Using deploytool for more information on using deploytool to accomplish these tasks:

User authentication method: The User Authentication Method box on the Security tab of deploytool enables you to specify how the user is prompted to log in. If specified, the user must be authenticated before it can access any resource that is constrained by a security constraint. The User Authentication Method options are discussed in Understanding Login Authentication.

Security constraints: The Security Constraint option is used to define the access privileges to a collection of resources using their URL mapping. Security constraints are discussed in Protecting Web Resources.

Web resource collections: The Web Resource Collections option is part of a security constraint and describes a URL pattern and HTTP method pair that refer to resources that need to be protected. Web resource collections are discussed in Protecting Web Resources.

Network security requirement: The Network Security Requirement option is used to configure HTTP basic or form-based authentication over SSL. Select a network security requirement for each security constraint. Network security requirements are discussed in What Is Secure Socket Layer Technology?.

Authorized roles: The Authorized Roles section is used to specify which roles that have been defined for an application are authorized to access this Web resource collection. The roles defined for the application must be mapped to users and groups defined on the server. Authorized roles are discussed in Setting Up Security Roles.

These elements of the deployment descriptor can be entered directly into the web.xml file or can be created using an application deployment tool, such as deploytool. This section describes how to create the deployment descriptor using deploytool.

Depending on the Web server, some of the elements of Web application security must be addressed in Web server configuration files rather than in the deployment descriptor for the Web application. This information is discussed in Installing and Configuring SSL Support, Using Programmatic Security in the Web Tier, and Setting Up Security Roles.

Protecting Web Resources

You protect Web resources by specifying a security constraint. A security constraint determines who is authorized to access a Web resource collection, which is a list of URL patterns and HTTP methods that describe a set of resources to be protected. Security constraints are defined using an application deployment tool, such as deploytool, as discussed in Setting Security Requirements Using deploytool or in a deployment descriptor.

If you try to access a protected Web resource as an unauthenticated user, the Web container will try to authenticate you. The container will accept the request only after you have proven your identity to the container and have been granted permission to access the resource.

Security constraints work only on the original request URI and not on calls made via a RequestDispatcher (which include <jsp:include> and <jsp:forward>). Inside the application, it is assumed that the application itself has complete access to all resources and would not forward a user request unless it had decided that the requesting user also had access.

Many applications feature unprotected Web content, which any caller can access without authentication. In the Web tier, you provide unrestricted access simply by not configuring a security constraint for that particular request URI. It is common to have some unprotected resources and some protected resources. In this case, you will define security constraints and a login method, but they will not be used to control access to the unprotected resources. Users won't be asked to log on until the first time they enter a protected request URI.

In the Java Servlet specification, the request URI is the part of a URL after the host name and port. For example, let's say you have an e-commerce site with a browsable catalog that you would want anyone to be able to access, and a shopping cart area for customers only. You could set up the paths for your Web application so that the pattern /cart/* is protected but nothing else is protected. Assuming that the application is installed at context path /myapp, the following are true:

http://localhost:8080/myapp/index.jsp is not protected.

http://localhost:8080/myapp/cart/index.jsp is protected.

A user will not be prompted to log in until the first time that user accesses a resource in the cart/ subdirectory.

To set up a security constraint, see the section Setting Security Requirements Using deploytool.

Setting Security Requirements Using deploytool

To set security requirements for a WAR, select the WAR in the deploytool tree, and then select the Security tabbed pane. In the Security tabbed pane, you can define how users are authenticated to the server and which users have access to particular resources. Follow these steps:

Choose the authentication method. Authentication refers to the method by which a client verifies the identity of a user to a server. The authentication methods supported in this release are shown next and are discussed in more detail in Understanding Login Authentication. Select one of the following authentication methods from the Authentication Method list:

None

Basic

Client Certificate

Digest

Form Based

If you selected Basic or Digest from the list, click Settings to go to the User Authentication Settings dialog box and enter the realm name in the Realm Name field (valid choices include file and certificate). If you selected Form Based, click Settings to go to the User Authentication Settings dialog box and enter or select the values for Realm Name, Login Page, and Error Page.

Define a security constraint. In the Security Constraints section of the screen, you can define the security constraints for accessing the content of your WAR file. Click the Add Constraint button adjacent to the Security Constraints field to add a security constraint. Double-click the cell containing the security constraint to change its name. Each security constraint consists of the following pieces:

A Web resource collection, which describes a URL pattern and HTTP method pair that refer to resources that need to be protected.

An authorization constraint, which is a set of roles that are defined to have access to the Web resource collection.

A user data constraint, which defines whether a resource is accessed with confidentiality protection, integrity protection, or no protection.

Define a Web resource collection for this security constraint. With the security constraint selected, click the Add Collections button adjacent to the Web Resource Collections field to add a Web resource collection to the security constraint. A Web resource collection is part of a security constraint and describes a URL pattern and HTTP method pair that refer to resources that need to be protected. Double-click the cell containing the Web resource collection to edit its name.

Edit the contents of the Web resource collection by selecting it in the list and then clicking the Edit Contents button. The Edit Contents dialog box displays. Use it to add individual files or whole directories to the Web resource collection, to add a URL pattern, or to specify which HTTP methods will be governed by this Web resource collection.

Select the files and directories that you want to add to the Web resource collection in the top text field, and then click the Add button to add them to the Web resource collection.

Add URL patterns to the Web resource collection by clicking Add URL and entering the URL in the edit field. For example, specify /* to protect all resources.

Select the options from the HTTP Methods list that need to be added to the Web application. The options are Delete, Get, Head, Options, Post, Put, and Trace.

Click OK to return to the Security tabbed pane. The contents of the Web resource collection display in the box beside the Edit Contents button.

Select the proper option from the Network Security Requirement list for this security constraint. The choices are None, Integral, and Confidential.

Specify NONE when the application does not require a security constraint.

Specify CONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.

Specify INTEGRAL when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit.

If you specify CONFIDENTIAL or INTEGRAL as a security constraint, that type of security constraint applies to all requests that match the URL patterns in the Web resource collection and not just to the login dialog box. For further discussion on network security requirements, see What Is Secure Socket Layer Technology?.

Select which roles are authorized to access the secure application. In the Authorized Roles pane, click Edit to specify which defined roles are authorized to access this secure application.

Select the role for which you want to authorize access from the list of Roles, and click the Add button to add it to the list of Authorized Roles.

If roles have not been defined for this application, click the Edit Roles button and add the roles for this application. If you add roles in this fashion, make sure to map the roles to the appropriate users and groups. For more information on role mapping, see Mapping Roles to Users and Groups.

To add security specifically to a JSP page or to a servlet in the application, select the JSP page or servlet in the deploytool tree and select the Security tab. For more information on the options displayed on this page, see Declaring and Linking Role References.

You can view the resulting deployment descriptor by selecting the WAR file in the deploytool tree and then selecting Descriptor Viewer from the Tools menu.

Specifying a Secure Connection

When the login authentication method is set to BASIC or FORM, passwords are not protected, meaning that passwords sent between a client and a server on a nonprotected session can be viewed and intercepted by third parties.

To configure HTTP basic or form-based authentication over SSL, specify CONFIDENTIAL or INTEGRAL as the network security requirement on the WAR's Security page in deploytool. Specify CONFIDENTIAL when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission. Specify INTEGRAL when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit.

If the default configuration of your server does not support SSL, you must configure it using an SSL connector to make this work. By default, the Sun Java System Application Server Platform Edition 8.0 is configured with an SSL connector. To set up an SSL connector on other servers, see Installing and Configuring SSL Support.

Note: Good Security Practice: If you are using sessions, after you switch to SSL you should never accept any further requests for that session that are non-SSL. For example, a shopping site might not use SSL until the checkout page, and then it may switch to using SSL in order to accept your card number. After switching to SSL, you should stop listening to non-SSL requests for this session. The reason for this practice is that the session ID itself was not encrypted on the earlier communications. This is not so bad when you're only doing your shopping, but after the credit card information is stored in the session, you don't want a bad guy trying to fake the purchase transaction against your credit card. This practice could be easily implemented using a filter.

Using Programmatic Security in the Web Tier

Web-tier programmatic security consists of the following methods of the HttpServletRequest interface:

getRemoteUser: Determines the user name with which the client authenticated.

isUserInRole: Determines whether a user is in a specific security role.

getUserPrincipal: Returns a java.security.Principal object.

Your application can make security decisions based on the output of these APIs.

Declaring and Linking Role References

A security role reference allows a Web component to reference an existing security role. A security role is an application-specific logical grouping of users, classified by common traits such as customer profile or job title. When an application is deployed, roles are mapped to security identities, such as principals (identities assigned to users as a result of authentication) or groups, in the operational environment. Based on this, a user with a certain security role has associated access rights to a Web application. The link is the actual name of the security role that is being referenced.

During application assembly, the assembler creates security roles for the application and associates these roles with available security mechanisms. The assembler then resolves the security role references in individual servlets and JSP pages by linking them to roles defined for the application.

The security role reference defines a mapping between the name of a role that is called from a Web component using isUserInRole(String name) and the name of a security role that has been defined for the application. For example, the mapping of the security role reference cust to the security role with the role name bankCustomer is shown in the following example.

Select the Web component in the deploytool tree.

Select the Security tab.

Select Add Constraints and Add Collections to add a security constraint and Web resource collection. Adding a security constraint enables the Edit Roles button.

Select the Edit Roles button to open the Authorized Roles dialog box. Click the Edit Roles button to open the Edit Roles dialog box. Click Add to add an authorized role to this application.

Click in the edit box and enter a role--for example, admin or loginUser. If you haven't added any users, refer to Managing Users for information on how to do so. Select OK to close this dialog box.

Select the role you just added in the left pane, and click Add to add it to the list of authorized roles for this application. Click OK to close this dialog box. The role you added displays in the list of Authorized Roles on the Security tabbed pane.

Now that you've set up a role for this application, you map it to the list of users and groups set up for the Application Server. To do this, follow these steps:

Log on to the localhost:4848 by double-clicking it in the deploytool tree. If you skip this step, the roles defined for the Application Server will not be displayed in subsequent steps.

Select the General tabbed pane.

Select Sun-specific Settings.

Select User to Role Mapping from the View list to map the users defined for the Application Server to roles defined for this application.

Select a role name in the Roles pane. These are the role names currently defined in the Authorized Roles for Security Constraint dialog box.

Click the Edit button under either Users or Groups. Use this dialog box to select a specific user or group to map to this role. Then click Add. If you selected a user, the name of the user will display in the Users Name pane when the role is selected in the Roles pane. If you selected a group, the name of the group will display in the Groups pane when that role is selected. When you defined users using the Admin Console, you provided them with a name, password, and group. Any users assigned to the group selected in this step will have access to the restricted Web application.

Select OK and then Close.

Select Save from the File menu to save these changes.

When you use the isUserInRole(String role) method, the String role is mapped to the role name defined in the Authorized Roles section of the WAR file's Security tabbed pane.

All of the material in The J2EE(TM) 1.4 Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.