SwingLabs Authentication Framework

The SwingLabs Authentication Framework is a general purpose framework for handling authentication tasks in your applications. For example, most database applications require that the user login to the database prior to issuing queries. An authentication framework assists in this task.

The SwingLabs authentication framework is part of the SwingX project. It is located in the org.jdesktop.swingx.auth package.

Overview

Many applications need to authenticate a user at some point. This common idiom doesn't have any built-in support in Swing. The SwingLabs authentication framework supports authentication in a flexible way by providing pluggable LoginService implementations.

The authentication framework comes with two built in LoginService implementations: JDBCLoginService and JAASLoginService. An additional LoginService that may prove to be quite useful would be an HTTPSLoginService. However, due to a possible dependence on third party libraries, such a LoginService will probably not be in core SwingLabs, but should be available in the optional packages. If you have a great implementation you'd like to submit, we'd be happy to give you some incubator space to show the world your great code!

This document only touches briefly the JXLoginPane, which is used to generate a login dialog or login frame. For more detailed information on that, see the JXLoginPane Tutorial

LoginService

The heart of the authentication framework is the LoginService. A LoginService is simply a pluggable strategy for authenticating the user. The LoginService's main method is:

     /**
     * This method is intended to be implemented by clients
     * wishing to authenticate a user with a given password.
     * Clients should implement the authentication in a
     * manner that the authentication can be cancelled at
     * any time.
     *
     * @param name username
     * @param password password
     * @param server server (optional)
     *
     * @return true on authentication success
     * @throws Exception
     */
    public abstract boolean authenticate(String name, char[] password, String server) throws Exception;
                        

As you can see from the code, there are three params to the authenticate method. Whether all or only some of the params are required is up to the LoginService you use. Many LoginServices don't require the Server param, for example, while others do.

The password is a character array for security purposes. Strings may be interned in the JVM, meaning that they are kept around and may be perused by anyone snooping around the JVM. Using a character array for passwords is the recommended practice by the security experts, so we follow that system here. Not to worry, the JPasswordField already returns the password as a character array, so there is usually very little code that needs to be written to get the password as a char[].

There are two concrete implementations of LoginService. JAASLoginService relies on the Java Authentication and Authorization Service as the basis for authentication. JAAS implementations exist for various schems such as LDAP (Active directory is also supported), Kerberos, and JNDI.

The other concrete implementation is the JDBCLoginService. As the name implies, JDBCLoginService authenticates against a database by using the supplied user name and password to try to connect. To use this login service, the user name and password must match that of a user for your RDBMS.

Saving User Names and Passwords

The SwingLabs authentication framework also provides basic support for saving the user names and passwords used for authentication. The base classes are UserNameStore and PasswordStore, respectively

UserNameStore contains a variety of methods for persisting user names. This document isn't going to go into detail, for more information on the API or writing a custom UserNameStore, check out the javadoc. However, it is worth mentioning the DefaultUserNameStore, which as the name implies is the default implementation. It uses the java.util.prefs package to persist the user names to Preferences. On Windows, the data is stored in the Windows registry by default.

Normal usage of DefaultUserNameStore is:

  DefaultUserNameStore userStore = new DefaultUserNameStore();
  //the next to lines specify where in prefs the user names should go
  //if this is not specified, then the usernames will be located in
  //the /org/jdesktop/swingx/auth/DefaultUserNameStore node.
  Preferences p = Preferences.systemRoot().node("/org/myapp/usernames");
  userStore.setPreferences(p);
  for (String name : userStore.getUserNames()) {
    System.out.println(name);
  }
  userStore.addUserName("Bob");
                        

Similarly, passwords are saved via a PasswordStore. However, unlike UserNameStore there is no default implementation of PasswordStore. A truly secure implementation is quite difficult, because the passwords must be encrypted. This is beyond the scope of this document.