ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Web FORM-Based Authentication

by Dion Almaer

In this article, we will walk through the various security settings that we can set up in the Web Application framework, going into detail on how you can set up FORM-based authentication.

All of the code from this article should work with any Web container that supports the Servlet 2.2 API and above. This article assumes that you have knowledge of Web applications, servlets, and JSP's.

We will walk through the following items:

  • Configuring security on a resource
  • The various authentication options
  • Using FORM-based authentication
  • Enforcing SSL

Configuring security on a resource

To secure a resource we will:

  • Restrict resources based on a given URL pattern
  • Name the security roles that are allowed access to the resources
  • Name all of the security roles in the Web application
  • Name all of the users/groups in the roles

Step One: Restrict resources based on a given URL pattern

First of all, we want to protect some resource in our Web container. We restrict an area of our site based on a URL pattern. So, let's restrict access to any URL that starts with /secure.

All of our configuration will take place in a file named web.xml that lives in the magical directory WEB-INF. This conforms to the Web Application standard defined by Sun (and company). In your web.xml file you will tell the Web container that you want to restrict an area based on the URL pattern, which will look like:

  <description>Security constraint /secure</description>

The interesting tags here are:

  • <url-pattern>: If a client accesses a URL that matches this pattern (in this case, accessing any resource under /secure), the container will make sure the user is authenticated before granting access to the resource

  • <http-method>: Here we declare what HTTP methods the security constraint will apply to. If we only had "GET" defined, then a POST request will not have to go through the security conditions. NOTE: If you do not specify a <http-method> then the security constraint will apply to all HTTP methods.

Step Two: Name the security roles that are allowed access to the resources

Now we have defined the area that we are securing, and what HTTP methods we will allow. We still need to tell the container who has access to this given resource. To do this we set up abstract security "roles" for our entire Web application, and list the roles that have access to each <security-constraint>. In our example we will only let users in the "admin" role have access to /secure (the SecurePages resource).

After the <web-resource-collection> we place an <auth-constraint> tag that tells the container "only the admin role has access to this area." For example,

<description>only let the admin users login</description>

Step Three: Name all of the security roles in the web application

Later on in web.xml we define all of the security roles. Our example only has one role (admin), but if you imagine a real-world example where you have /managers and /peons, each with their own roles, then you would configure the "manager" and "peon" roles, but the <auth-constraint> for each resource will only list one role (e.g. under the <security-constraint> that has the pattern /managers/*, the <role-name> would be "manager").

Here is the simple <security-role> tag showing our only role (admin):

  <description>The Only Secure Role</description>

Step Four: Name all of the users/groups in the roles

So, we have listed all of our security roles, told the server that anyone in that one role is allowed access to a resource under /secure, but how do we set up the users that are in the given role? A "role" is just this abstract thing, but we need to tie it to the real security system. This is where we move away from the standards, and the particular server takes over.

If we are working with BEA WebLogic Server, we tie to the real users via the file WEB-INF\weblogic.xml. That file would have the following xml:


We tie to the role name admin, and give the usernames, or groups that are part of that role. In this case, I have only granted access to /secure to the user "system."

To put it all together, so far we have set up the security roles for our Web application, named all of the users and groups that are part of that role, and set up a security condition: when a browser accesses /secure, only the users in the admin role will get through!

Authentication Options

Although we have defined the users that are allowed access to a resource, we need to tell the container how we want to authenticate the users. There are four authentication methods to choose from:

Authentication Method Description

Use HTTP basic authentication. If we used this setting then the good ole pop up window will show trying to access /secure.


It is sometimes nice to be able to build your authentication into your Web pages. With FORM-based authentication we can do this! We will focus on this mechanism in the next section.


We can use client digital certificates to authenticate against.


Use HTTP digest authentication (advanced form of BASIC, but hasn't caught on to much).

This is a nice feature, being able to choose the authentication mechanism at deploy-time. Let's check out form based authentication, and walk through an example of setting it up.

Pages: 1, 2

Next Pagearrow