Introduction

For Web applications that do not exchange sensitive information with clients, it is best to use a transport layer setting that does not enforce content integrity (preventing tampering in transit) or confidentiality (preventing reading data during transfer). Doing so lets the server handle more responses per second than if all data exchanged between server and client were encrypted. However, you should keep authentication credentials (user IDs and passwords) exchanged between client and server confidential and not transmit them in clear text, even when the Web application does not enforce any special settings for the transport layer, so that you prevent any unauthorized access to data.

This article shows you how to protect only user IDs and passwords, and not other information exchanged between client and server. You can download a sample application that includes all files described in this article. Also, you can easily apply the concepts discussed here to complex Web applications where security requirements are different -- more Web resources to secure, multiple roles for authenticated users, and so on.

The software configuration used in this article is shown in Figure 1:

Assumptions

This article assumes that you know how to:

• Enable global security for IBM ® WebSphere® Application Server.
• Configure WebSphere Application Server to use a valid user registry to authenticate users.
• Configure an SSL transport for the WebSphere Application Server plug-in and WebSphere Application Server.
• Configure an SSL transport for the HTTP Server and the browser client.
• Create and use a test environment server in WebSphere Studio Application Developer (hereafter called Application Developer).
• Deploy EAR applications on WebSphere Application Server.
• Understand the concepts of a J2EE application (EAR file) and a Web module application (WAR file).

If you are not familiar with any of the above security items, study Chapter 10 (Administering WebSphere Security) of the IBM WebSphere V5.0 Security Handbook. If you need more information on installation and configuration of J2EE applications, see IBM WebSphere Application Server V5.0 System Management and Configuration Handbook.

Here are the steps to enable SSL only for the login page of the sample Web application:

Back to top

1. Creating a form-login page for the Web application

WebSphere Application Server lets applications present site-specific login forms by using of the form-login authentication method.

Whenever an unauthenticated user tries to access a secure resource in the Web application, the user is redirected to the form-login page, which takes the user to an HTML form that gathers authentication information. The user enters his or her user ID and password into the form and submits it to the server. This submission triggers a special WebSphere Application Server servlet that performs authentication of the user on behalf of the application. If the user's credentials are valid (authenticate successfully), the originally requested protected resource is then accessed. If authentication fails, the request is routed to a login error page. The form-login mechanism lets you specify which page in your Web application should be used as the login error page.

In this example, a JSP page is used as the implementation for the form-login page (we recommend using a JSP page instead of an HTML static page because you may encounter URL redirection problems when using an HTML page). The JSP login page has text-entry fields for a user ID and password. The HTML form included in the JSP login page must meet the following criteria so that WebSphere Application Server can extract the user credentials from it and compare them against the user registry:

• The text-entry field for the user ID must be named j_username.
• The field for the password must be named j_password.
• The post action must be j_security_check. This action ensures dispatch to a special servlet that verifies the user credentials that were collected by the form.

Figure 2 shows the definition of our form-login page in Application Developer. To get to this screen, open the Web descriptor in Application Developer and select the Pages tab. For more detailed information on creating a form-login page, see WebSphere Application Server v5 information center and look for the Form login sub-section under the Security section. The JSP login page and the login error page should be included in your WAR file with the rest of the files that constitute your Web module. In the sample, the JSP login page is named login.jsp and the login error page is named loginError.html.

Back to top

2. Creating security roles

A security role that groups all authenticated and unauthenticated system users must be created. In the example, this role is called everyone. To create this role:

1. Open the Web deployment descriptor of your Web application in Application Developer.
2. Click on the Security tab.
3. Make sure the Security Roles panel is selected.
4. Click Add to add a security named everyone.

Figure 3 shows the security roles created for our sample Web application:

Next, we defined a role named authenticated_user, which groups all users that have been authenticated by the system. To create this role, follow the same steps specified above. Depending on the requirements for your Web application, you might need more than a general role that groups all authenticated users (for instance, you might need to differentiate between manager users and employee users).

Back to top

3. Configuring a security constraint for the login page

Next, you must define a security constraint that enforces an SSL connection to access the form-login page, to ensure that user IDs and passwords are kept confidential and not transmitted in clear text:

1. Open the Web deployment descriptor of your Web application in Application Developer.
2. Click on the Security tab.
3. Select the Security Constraints panel.
4. Click Add to add a new security constraint.
5. In the Web Resource Collections section of the panel, click Add to specify a name and the URL pattern for this collection. The URL pattern is the string that follows the context root of your Web module in order to access the form-login page. Since we named our form-login page login.jsp, our URL pattern is /login.jsp.
6. When defining this constraint, make sure the user data constraint type is Confidential and that everyone is selected as the authorized role that can access the resources that fall under this security constraint.

Figure 4 shows the security constraint we defined for our form-login page:

Back to top

4. Configuring security constraints for resources in the protected Web application

Next, you need to define a second security constraint. Depending on your requirements, you might need more than two security constraints. To keep it simple, we define only one more security constraint that applies to the resources within your Web application that you want to secure without requiring a confidential transport (SSL) to exchange data. The sample application has a servlet that should be accessed only by authenticated users. If an authenticated user tries to access this servlet, the request should be redirected to the secure login page. The name of this servlet is SecureServlet.

1. Open the Web deployment descriptor of your Web application in Application Developer.
2. Click on the Security tab.
3. Select the Security Constraints panel.
4. Click Add to add a new security constraint.
5. In the Web Resource Collections section of the panel, click Add to specify a name and any URL patterns for the resources you want to secure. A URL pattern is the string that follows the context root of your Web module in order to access a resource contained in your Web application. In our case, we only have one resource to secure: SecureServlet. Since this is the only resource we want to secure and the URL mapping for this servlet is /SecureServlet, the only URL pattern for this collection is /SecureServlet.
6. When defining this constraint make, sure that the user data constraint type is None and that authenticated_user is selected as the authorized role that can access the Web resources under this security constraint.

Figure 5 shows the security constraint we defined for the SecureServlet Web resource:

Back to top

5. Mapping security roles using the WebSphere binding extension properties

In this step, we establish the relationship between the security roles that we defined previously and their authentication status.

1. Open the EAR deployment descriptor of the EAR application that contains your Web module application in Application Developer.
2. Click the Security tab.
3. Click Gather to display the security roles we defined previously at the EAR level. In our case, these are everyone and authenticated_user.
4. Use the WebSphere binding extension properties to map the security roles to an authentication status. This option is on the right side of the Security tab. In our case, for the everyone role, we made sure that only the Everyone checkbox was selected. For the authenticated_user role, make sure that only the All authenticated users checkbox is selected. Depending on your requirements, you might need to further define which users within the authenticated users group are granted access to a Web resource.

Back to top

6. Testing the security configuration for the Web application

Now it is time to test all the configuration work, using the Application Developer WebSphere Test Environment (WTE). Select a WTE server instance for WebSphere Application Server V5. Deploy to this server the EAR application that contains your Web module application. If you do not have an existing WTE server (for WebSphere Application Server V5), you can create one. Make sure that global security is enabled and configured correctly for this WTE server.

Start your WTE server and then try to access a protected resource in your Web application. In our case, this is the SecureServlet, so launch a browser and type in the address field: http://localhost:9080/exampleApp/SecureServlet (the context root for our sample application is exampleApp). The server should reroute this request to the form-login page and the protocol in the browser should be HTTPS and not HTTP. Once the login page has been rendered by your browser, enter a valid user ID and password. After you have submitted the form, the request should be redirected to the resource you originally intended to access using the HTTP protocol.

Back to top

7. Installing the EAR application on WebSphere Application Server V5

After the Web application has been successfully tested in WTE, you can deploy it on WebSphere Application Server. If you would like to first test the J2EE sample application provided with this article (TESTEAR.ear), you can install this one instead. We used the admin console to install the J2EE application on the application server. Before testing the application on the application server, verify the following application server settings:

• Global security is enabled and properly configured for the application server.
• The Web container where your application is hosted has one transport that is not confidential (HTTP) and one that is (HTTPS). Usually, TCP/IP port 9080 is used as the default unsecured transport and TCP/IP port 9443 is used as the secure transport (check this by using the admin console). These settings ensure that a communication path is always available for the WebSphere Application Server plug-in whenever it needs a confidential transport to communicate with the application server.
• A *:443 host alias exists under the virtual host associated with your Web application. It guarantees that HTTPS requests that match the context root of your Web application are routed to the application server. We used default_host as the virtual host for the sample application.
• The HTTP Server is configured to use both protocols (HTTP and HTTPS) and not just HTTPS. If you allow only HTTPS connections to the HTTP Server, then all data exchanged between client and server will be encrypted and secure regardless of the user data constraint that you specified for the resources in your Web module.

It is beyond the scope of this article to explain how to configure global security in WebSphere Application Server. Also, it is not the intent of this article to describe how to generate the keys and certificates that are required for the Web container, the WebSphere Application Server plug-in, and the HTTP Server in order to establish an SSL communication transport among them. As mentioned earlier, the IBM WebSphere V5.0 Security Handbook is an excellent resource for this information. However, it is worth showing here the changes that you should make to the main configuration file (httpd.conf) of the HTTP Server to enable SSL:

For a UNIX system, add the following lines:

LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so
AddModule mod_ibm_ssl.c

On Windows®, use:

LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll

If the line Port 80 is present, comment it out.

Add these two lines if they are not present in the configuration file:

Listen 80
Listen 443

Next, create a VirtualHost entry to let the HTTP Server service encrypted HTTPS requests on TCP/IP port 443. The scope of the SSL support is limited by specifying the SSLEnable directive within the VirtualHost tags. The SSLServerCert directive is not required if you only have a single VirtualHost. You can use this directive to associate a unique SSL server certificate label with a specific VirtualHost. In our case, since HttpServerCertificate was the key label we used for the HTTP Servers self-signed certificate, we use that same value for the SSLServerCert directive:

# Change the property values shown here so they match your
# HTTP Servers settings (i.e., IP address, hostname, server path)
<VirtualHost 10.0.0.1:443>
ServerName roliv.austin.ibm.com
SSLServerCert HttpServerCertificate
ServerPath c:/ibmhttpserver/htdocs
SSLEnable
</VirtualHost>

To make sure SSL is not used globally, use the SSLDisable directive after closing the VirtualHost entry. The SSL timeout values apply to any VirtualHost entries defined for the HTTP server instance, since they are specified outside the VirtualHost entry. The keystore to use for this server is globally specified as well. The settings used in our example are:

SSLDisable
# The Keyfile directive should point to the file where you store
# your HTTP Servers certificate
Keyfile c:/ibmhttpserver/certs/webServerKeyStore.kdb
SSLV2Timeout 100
SSLV3Timeout 1000

Once you have successfully tested the security settings for each one of the software resources (HTTP Server, WebSphere Application Server, and the WebSphere Application Server plug-in for the HTTP Server) that participate in the processing of browser requests, then you are ready to test the Web application. Open a browser and enter the URL http://<server_name>/<context_root>/<secure_resource>. It translates to http://localhost/exampleApp/SecureServlet. Your browser should be redirected to the form-login page using the HTTPS protocol. If you are using our sample application, this page is https://localhost/exampleApp/login.jsp. After you enter a valid user ID and password, your browser should be redirected to the resource you originally intended to access using the HTTP protocol.

Back to top

Conclusion

Some Web applications do not require a transport layer that enforces content integrity and confidentiality. Using an SSL transport for such applications wastes computational resources and degrades performance. This article has shown you how to configure a Web module so that SSL is used only for the transmission of user IDs and passwords. In this way, you can greatly improve performance and still prevent transmission of user IDs and passwords in clear text, thus preventing unauthorized access to the data.

Back to top

Download

Name	Size	Download method
SSLTestApp.zip	4 KB	FTP|HTTP

Information about download methods

Resources

• WebSphere Application Server V5 information center
  
  
• WebSphere V5.0 Security Handbook (IBM Redbook, December, 2002)
  
  
• WebSphere Application Server V5.0 System Management and Configuration (IBM Redbook, April, 2003)
  
  
• HTTP Server (powered by Apache): An Integrated Solution for IBM iSeries Servers (IBM Redbook, October, 2003)
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• 1. Creating a form-login page for the Web application
• 2. Creating security roles
• 3. Configuring a security constraint for the login page
• 4. Configuring security constraints for resources in the protected Web application
• 5. Mapping security roles using the WebSphere binding extension properties
• 6. Testing the security configuration for the Web application
• 7. Installing the EAR application on WebSphere Application Server V5
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers