Covering J2EE Security and WebLogic Topics

Authentication Methods in Web Applications

According to the Java Servlet Specification, there are four standard methods of authentication in web applications: FORM, BASIC, DIGEST, and CLIENT-CERT. FORM is quite common, but BASIC and DIGEST are not. CLIENT-CERT is primarily used for client certificate authentication but it has more to offer than you might imagine from the name.

First, let’s have a look at a web.xml snippet to see where the authentication methods go.


  <!-- The following stanza is for the FORM method only -->

As you can see, it’s the auth-method element that can be FORM, BASIC, DIGEST, or CLIENT-CERT. Assuming you are sticking with one of these standard container-managed authentication schemes, this is the only place where authentication is configured. J2EE-compliant servlet engines such as the one in WebLogic use the configuration information in web.xml to handle authentication without any custom code on your part.

Regardless of the authentication method, the server will only attempt to authenticate the user when he tries to access a protected resource.

Let’s turn our attention now to each authentication method in turn.


FORM is by far the most common type of authentication for web applications. With FORM, the server will display a web page (with an HTML FORM element) for entering a username and password the first time the user tries to access a protected resource. Upon successful authentication (which is handled by the server), the server automatically redirects the authenticated user to the protected page that he requested assuming that the user is also authorized to see the page.

The reason FORM is so popular is that this is the only standard authentication type that allows you to customize the look and feel of the login page and have it essentially be a part of your application. You tell the server which page to display with the form-login-page element. The page specified in the form-error-page element is displayed when the user fails authentication. The pages can be different or the same. I like to use the same page but pass an error parameter to indicate authentication failure as shown in the XML snippet above. The login page can check for the error parameter to conditionally display a message such as “Authentication Failed” along with the username and password textboxes for the user to try again.

Although the design of the login page is totally up to you, there are three conventions that you must follow for authentication to work:

  • The action for the form must go to “j_security_check”
  • The username textbox must be named “j_username”
  • The password textbox must be named “j_password”

j_security_check is a hidden system servlet that delegates to the server’s security framework to determine if the username (specified by j_username) and the password (specified by j_password) positively identify the user.

Here’s a very ugly login form that demonstrates the requirements of a login form:

    <form method="POST" action="j_security_check" >
      Username: <input type="text" name="j_username"><br/>
      Password: <input type="password" name="j_password"><br/>
      <input type="submit" value="Log In">


The BASIC method of authentication has a face only Tim Berners-Lee could love. The technique is defined in the HTTP/1.0 specification and presents a browser-supplied dialog box for the user to supply his username and password. Upon successful authentication, the user will be presented the requested page assuming the user is subsequently authorized to see it.

This form of authentication is ugly and out of place. Sort of like myself in high school. (There’s no need to make any comments that those adjectives still apply!) Ahem. Moving right along…


The DIGEST method of authentication is an attempt at fixing the deficiencies of BASIC authentication. It’s rarely used and not required by the servlet specification. Because of this, I won’t cover it any more than I just did.


The CLIENT-CERT authentication method is typically used for identifying the user by his X.509 certificate. This is a special usage of the Secure Sockets Layer (SSL) where both the server and the user are identified by their own certificates. As a result, this is a very strong form of authentication.

Encounters with SSL on the Internet are almost always one-way authentication where only the server presents a certificate to the client. Think of ordering on, for example. The protocol switches from http to https and the little lock symbol appears on your browser. This signifies that the link is encrypted and the certificate presented by Amazon was trusted since your browser trusts certificates issued by Verisign. (Note: Public Key Infrastructure (PKI) and trust are beyond the scope of this post.) Even so, the server still does not know the identity of the user. User authentication is left to another mechanism such as username/password.

On the other hand, two-way SSL retains the server authentication part but adds the requirement that the client present a certificate that the server trusts. Assuming that both sides agree, the encrypted link is established and both sides are mutually authenticated via SSL. This technique is rare on the Internet since most people don’t have personal certificates. However, there is traction for two-way SSL on corporate intranets and in B2B scenarios. Once a mutually authenticated link is established, there is no further need for user authentication since the certificate already positively identified the user.

Whew, that was a lot of backstory on two-way SSL. Hopefully, though, the purpose of the CLIENT-CERT auth-method is now clear. Using CLIENT-CERT means that your application wants to authenticate the user via two-way SSL.

But wait, there’s more… ๐Ÿ˜‰

Configuring CLIENT-CERT

Specifying CLIENT-CERT in web.xml is not sufficient for actually having the whole process work. I won’t go into details, but here are the additional configuration items you need to handle:

  • Ensure that your server has a server certificate
  • Ensure that your user’s trust your server certificate’s issuer (the CA certificate)
  • Ensure that your server’s is listening on the SSL port
  • Ensure that your user’s have certificates
  • Ensure that your server trusts the user certificate issuer(s)
  • (WebLogic) Ensure that an Identity Asserter handles the X.509 certificate and can map the certificate to a known user

The list above describes in general terms what must be configured for mutual authentication to work. In WebLogic, it’s an identity assertion security provider that handles X.509 certificates. The identity asserter isn’t triggered unless CLIENT-CERT is present in web.xml.

Once all of this is properly configured, the stars line up just so, and you dispose of the hair you pulled out trying to get it right, you’re ready to enjoy authentication via two-way SSL.

But wait, there’s more…

Perimeter Authentication Tokens

According to the servlet specification, the intention of the CLIENT-CERT authentication method was for two-way SSL as described above. However, BEA WebLogic not only supports the spec but expands upon it to support any type of perimeter authentication token.

With WebLogic, X.509 certificates, SAML tokens, Kerberos tickets, etc., are all examples of perimeter authentication tokens. Of the examples presented, the WebLogic 8.1 security framework only supports X.509 out of the box, but you can write or buy custom identity asserters that handle any type of token that can be presented as string. That’s pretty nifty.

And it all starts with the mysterious CLIENT-CERT authentication method.

1 Comment

  1. […] authentication and authorization Updated with New video ASP.NET authentication and authorization Bastion ยป A blog about J2EE Security, WebLogic, authentication, authorization, auditing, and PKI According to the Java Servlet Specification , there are four standard methods of authentication in […]

    Pingback by Security | Pearltrees — April 5, 2013 @ 3:48 pm

Sorry, the comment form is closed at this time.


Bookmark this page on