Standard form authentication Java servlets

Question

What is the standard way of doing form authentication with Java Servlets?

Since now I have implemented that myself using a simple POST HTML form:

1. checking the sent parameters against the database
2. if present, save a User object into the HttpSession
3. check in every Servlet whether this object is present
4. if not: redirect to the login page with an error message

But now I have stumbled over How to Configure Security with Embedded Jetty and now I am thinking of that I can reuse already implemented solutions to that problem, but what is the standard approach here? I am using Jetty myself, but what about Tomcat or other web servers?

I also read about j_security_check, what's with that? Is that a legacy method?

Answer 1

You should be using JAAS security provided by Servlet containers like Tomcat, Websphere, Glassfish.

By default these containers supports these authentication types:

• BASIC
• DIGEST
• FORM
• CLIENT-CERT

HTTP Basic Authentication

Specifying HTTP basic authentication requires that the server request a user name and password from the web client and verify that the user name and password are valid by comparing them against a database of authorized users in the specified or default realm.

Basic authentication is the default when you do not specify an authentication mechanism.

When basic authentication is used, the following actions occur:

1. A client requests access to a protected resource.
2. The web server returns a dialog box that requests the user name and password.
3. The client submits the user name and password to the server. 4.\The server authenticates the user in the specified realm and, if successful, returns the requested resource.

The below Figure shows what happens when you specify HTTP basic authentication.

HTTP Basic Authentication Diagram of four steps in HTTP basic authentication between client and server

Form-Based Authentication

Form-based authentication allows the developer to control the look and feel of the login authentication screens by customizing the login screen and error pages that an HTTP browser presents to the end user. When form-based authentication is declared, the following actions occur.

1. A client requests access to a protected resource.
2. If the client is unauthenticated, the server redirects the client to a login page.
3. The client submits the login form to the server.
4. The server attempts to authenticate the user.
5. If authentication succeeds, the authenticated user’s principal is checked to ensure that it is in a role that is authorized to access the resource. If the user is authorized, the server redirects the client to the resource by using the stored URL path.
6. If authentication fails, the client is forwarded or redirected to an error page.

The below Figure shows what happens when you specify form-based authentication.

When you create a form-based login, be sure to maintain sessions using cookies or SSL session information.

For authentication to proceed appropriately, the action of the login form must always be j_security_check. This restriction is made so that the login form will work no matter which resource it is for and to avoid requiring the server to specify the action field of the outbound form. The following code snippet shows how the form should be coded into the HTML page:

<form method="POST" action="j_security_check">
  <input type="text" name="j_username">
  <input type="password" name="j_password">
</form>

Digest Authentication

Like basic authentication, digest authentication authenticates a user based on a user name and a password. However, unlike basic authentication, digest authentication does not send user passwords over the network. Instead, the client sends a one-way cryptographic hash of the password and additional data. Although passwords are not sent on the wire, digest authentication requires that clear-text password equivalents be available to the authenticating container so that it can validate received authenticators by calculating the expected digest.

References:

• How to Secure My Web Applications
• Securing Web Applications
• Securing Java EE 5 Web Applications
• Declaring Security Requirements in a Deployment Descriptor
• Client Cert Authentication