email article printer friendly get the code

Put Convenience into Web Applications
A custom class applies form-based authentication—balancing convenient logon features with security
by Brett Spell

September 6, 2004

Security decisions for businesses' Web-based applications often require balancing the need for security with their users' desire for convenience. Perhaps the most obvious example is how we choose to handle session timeouts in a J2EE application. If your company works with Apache's Tomcat server, as many do, your options are limited by default. Before we discuss how to overcome these limitations, let's review sessions and how they're used.

A session is a mechanism for maintaining state across multiple requests made by a user's Web browser. If there is a request for a checkout on a retailer's Web site, the server must know which items are for purchase for the server to be able to perform any type of meaningful operation. HTTP is stateless by nature, which in this context means that it doesn't automatically associate (for example) a "checkout" request with a previous "add this item to my shopping cart" request. In other words, HTTP by default treats each request as separate and unrelated to other requests, and it's that limitation that sessions are designed to overcome.

Sessions are used commonly to allow a server to save authentication information for users when they log on to allow them to access protected resources without having to send their logon information with each request. For example, if a credit card company has a Web site, it probably allows users to log on and then issue requests to see information regarding their account. This kind of access is possible because the server creates a session for each user, assigns it a unique identifier, and sends that identifier to the user's browser. The browser includes that identifier in requests it makes to the server, allowing the server to quickly determine the user is authorized to access the requested information.

Take Five
Continuing with the credit card example, what happens if users forget to log off the Web site when they're finished or if the Web site doesn't provide an explicit way to log off? Leaving a user logged on indefinitely to a site that reveals credit information isn't desirable, particularly if the user happens to share a computer with other people who shouldn't have access to that information. The Java servlet API's solution to this problem is to allow an application to define a session timeout value that tells the server to end the session if it doesn't receive any requests for that session within a specified amount of time. For example, suppose that your web.xml file includes:

<session-config>
  <session-timeout>15
  </session-timeout>
  </session-config>

With this setting, the server will consider a session to have ended if 15 minutes elapse without receiving a request for that session. Once a session ends, the server no longer remembers the logon, and the user will be unable to access protected resources until logging on again. In effect, the server logs off the user automatically after 15 minutes of inactivity.