Skip to main content

Repost: Using JAAS with JSF

Posted by edburns on March 7, 2006 at 1:33 PM PST

The content and ideas in this blog entry are taken from my upcoming
McGraw Hill Osborne book href="">JavaServer Faces: The Complete
Reference, which I am co-authoring with href="">Chris Schalk. In the
book, we have a chapter on Securing JavaServer Faces applications. This
excerpt shows how the extensible design of JavaServer Faces can be used
to allow JAAS to provide authentication to a JSF Web application. JAAS
Authorization with JSF is also covered in the book, but not in this

We will conclude this chapter by showing how to enhance the example
application by leveraging the standard security infrastructure of the
Java platform. From its inception, the Java platform has treated
security as a first class concern. Indeed, one of the first benefits of
Java was to securely bring dynamic behavior to web deployed
applications. Over the years, the implementation and API to security
has evolved, but the core principals have improved and become steadily
more secure. Therefore, choosing to build your application managed
security on top of the standard Java security features is a very safe

A term often applied to Java security is JAAS, which is short for
Java Authentication and Authorization Service. JAAS started out as an
optional package in JDK 1.3 but has become a core part of the Java
platform as of JDK 1.4. As the name implies, JAAS covers the first two
of the three main aspects of security: authentication and authorization.
Let's explore one way to integrate JAAS style authentication and
authorization into the application

Using JAAS Authentication in the example application

While it would certainly be possible to call into the JAAS layer
directly from the example application logic, for example, from the
UserRegistry bean, a more re-usable solution is to encapsulate the JAAS
interface in a custom ActionListener. This approach de-couples the
security completely from your application and takes advantage of the
intended use of the ActionListener extension hook.

The mechanics of providing such an ActionListener are described in
Chapter 11, but let's review briefly here. The first step is to modify
the faces-config.xml file for the example reusable component library so
that it includes the action-listener declaration, as shown here.


Then, leverage the decorator pattern, as described in Chapter 10, to
delegate most of the work to the "real" ActionListener by providing a
constructor that saves a reference to it. Following the constructor,
the processAction( ) method must be implemented, as described below.

private ActionListener parent = null;
public JAASActionListener(ActionListener parent) {
  this.parent = parent;

public void processAction(ActionEvent event)
  throws AbortProcessingException {
  FacesContext context = FacesContext.getCurrentInstance();
  UIOutput comp = null;
  String userid = null, password = null;
  JAASHelper jaasHelper = new JAASHelper();
  // Check to see if they are on the login page.
  boolean onLoginPage = (-1 != context.getViewRoot().getViewId().
      lastIndexOf("login")) ? true : false;
  if (onLoginPage) {
    if (null != (comp = (UIOutput)
      context.getViewRoot().findComponent("form:userid"))) {
      userid = (String) comp.getValue();
    if (null != (comp = (UIOutput)
      context.getViewRoot().findComponent("form:password"))) {
      password = (String) comp.getValue();
    // If JAAS authentication failed
    if (!jaasHelper.authenticate(userid, password)) {
          handleNavigation(context, null, "login");
    else {
      // Subject must not be null, since authentication succeeded
      assert(null != jaasHelper.getSubject());
      // Put the authenticated subject in the session.

The first thing to note is that part of the usage contract for
JAASActionListener is the requirement that the username and password
components be nested inside a UIForm named "form", and be named "userid"
and "password" respectively. This expedient measure allows the
JAASActionListener to easily extract the user-provided values for
username and password so that they can be passed on to the JAASHelper
class. The second thing to note about the usage contract is the
requirement that the application provide a navigation rule for the
outcome "login" that causes the user to be directed to the login page if
the authentication failed. In the failure case, processAction( ) is not
called until after redirecting to the "login" outcome using
NavigationHandler. If authentication succeeded, the Subject is stored
in the session for later access. The is the Java
class that represents the user to the runtime. (We'll cover Subject in
greater detail in the section on JAAS authentication.) Finally, the
parent processAction( ) method is called to do the normal action
handling. Note that this causes the existing application managed
authentication, as described in Chapter 9, to take place. A production
quality implementation would probably remove the application managed
authentication in favor of using JAAS, rather than just supplementing
it, as we have done here.

Let's examine the JAASHelper class.

public class JAASHelper {
  LoginContext loginContext = null;

  public JAASHelper() {
  public boolean authenticate(String userid, String password) {
    boolean result = false;
    try {
      loginContext = new LoginContext("FileLogin",
          new LoginCallback(userid, password));
      result = true;
    catch (LoginException e) {
      // A production quality implementation would log this message
      result = false;
    return result;
  public Subject getSubject () {
    Subject result = null;
    if (null != loginContext) {
      result = loginContext.getSubject();
    return result;
  public static class LoginCallback implements CallbackHandler {
    private String userName = null;
    private String password = null;
    public LoginCallback(String userName, String password) {
      this.userName = userName;
      this.password = password;
    public void handle(Callback[] callbacks) {
      for (int i = 0; i< callbacks.length; i++) {
        if (callbacks[i] instanceof NameCallback) {
          NameCallback nc = (NameCallback)callbacks[i];
        } else if (callbacks[i] instanceof PasswordCallback) {
          PasswordCallback pc = (PasswordCallback)callbacks[i];

The authenticate( ) method uses the class to perform the login. The login(
) method of this class will throw a LoginException if the login fails
for any reason. This exception is caught by authenticate( ) and it
responds by setting result to false. false. If no exception is thrown,
result is set to true. authenticate( ) ends by returning the value of

The two arguments to the LoginContext constructor are the most
important part of this example. The first, the literal string
"FileLogin", refers to an implementation of the interface. This interface is
implemented by a provider of a particular implementation of
authentication technology, for example JNDI, LDAP, or database. In this
example, we use a free software implementation called "tagish" that
provides a simple file based authentication scheme. The implementation
comes from John Gardner and can be found at href="">
Providing a LoginModule implementation is beyond the scope of this
chapter, but we must illustrate how to use one, once it has been
provided. This is the beauty of JAAS, the authentication technology
itself is separated from the rest of the system. In other words, if you
want to plug in LDAP, do it by providing a custom LoginModule.

The JVM is made aware of the existence of a LoginModule
implementation either through a -D flag, or via a modification to the
JAVA_HOME/jre/lib/ file. In our case, we use
the former option:

Note the use of forward slashes instead of the standard Windows
backslashes. Also note the "==" instead of just one "=". The format of
this file is prescribed by JAAS:

  com.tagish.auth.FileLogin required

The FileLogin identifier must match the argument to the LoginContext
constructor. The first element inside the FileLogin declaration is the
fully qualified class name of the class implementing LoginModule. In
our application, we have bundled tagish.jar, which contains this class,
into the WEB-INF/lib directory of the application. The required flag
tells the system that the login must succeed, and whether it succeeds or
fails, the login must still proceed down the LoginModule chain. Other
valid values for this flag are requisite, sufficient, and optional and
are described in the javadocs for the class The pwdFile argument is an
implementation specific parameter to the code in tagish.jar that tells
it where to find its password file. The format of this file is also
implementation specific and for the example app looks like this:

username:MD5 Hash Of Password:group*
The specific file for the example follows:
# Passwords for com.tagish.auth.FileLogin


Obviously, a simple MD5 hash of the password is not at all secure and
a production quality implementation would use an actual encryption
algorithm. For the purposes of security, MD5 is just as secure as
Base64 encoding, described earlier in the chapter, which is to say, not
at all secure. A handy MD5 hash calculator can be found at Note that user jake is a
member of the user and manager groups, while all the other users are
simply members of the user group. Groups will come into play in the
next section.

The second argument to the LoginContext constructor is an
implementation of the
interface. The LoginCallback implementation saves the username and
password ultimately originating from the userid and password components
in its constructor and uses standard boilerplate code to propagate them
to the JAAS system.

Technorati Tags:

Related Topics >>