Custom JAAS Realm for Glassfish 3

Building a custom JAAS realm for Glassfish 3 is actually quite straight forward, as long as you know how to do it :) The documentation available around is not very clear and it takes some time to collect the required info on the web and to get it working. So here is a short sum-up of the process.

The first thing to do is to build a realm specific JAR file that is deployed in the Glassfish’s domain directory. This JAR file contains a Realm handler, describing the realm and handling the realm groups, and the ‘LoginModule’ responsible to perform the authentication.

In case of Glassfish 3, we don’t need to develop an entire JAAS solution. We can easily base our solution on some helper classes, as shown hereafter.

Let’s go for the JAR file…

First, the Maven POM (which is generally a sub-module of a project POM, as in this example):

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">




   <name>MyRealm JAAS Module</name>


      <!-- '' has a dependency to 'javax.persistence'. However, it is currently broken in the and JBoss repositories. To avoid the compilation to stop, we get the dependency directly from Eclipse. Later, this explicit dependency might be removed. -->




       <!-- See above -->

           <name> Repository for Glassfish</name>

       <!-- Alternative to the repository -->




Now the Realm handler class:

package eu.lucubratory.myrealm;


import java.util.Enumeration;
import java.util.Properties;
import java.util.Vector;

 * Extends the default implementation provided by "AppservRealm" as requested by
 * in order to make the realm
 * declaration complete.
public class MyRealm extends AppservRealm {

   private static final String JAAS_CONTEXT="jaas-context";

   public MyRealm() {

    * Initialize a realm with some properties. This can be used
    * when instantiating realms from their descriptions. This
    * method may only be called a single time.
    * @param properties - Key-value pairs defined in the Console's Realm declaration.
    * @exception BadRealmException if the configuration parameters identify a corrupt realm
    * @exception NoSuchRealmException if the configuration parameters specify a realm which doesn't exist
   public void init(Properties properties) throws BadRealmException, NoSuchRealmException {

       System.out.println("Init MyRealm");

       // Pass the properties declared in the console to the system
       String propJaasContext=properties.getProperty(JAAS_CONTEXT);
       if (propJaasContext!=null) {
          setProperty(JAAS_CONTEXT, propJaasContext);

    * Returns a short (preferably less than fifteen characters) description
    * of the kind of authentication which is supported by this realm.
   public String getAuthType() {
      return "CustomHardcoded";

    * Returns the name of all the groups that this user belongs to.
    * @param username name of the user in this realm whose group listing is needed.
    * @return enumeration of group names (strings).
    * @exception InvalidOperationException thrown if the realm does not
    * support this operation - e.g. Certificate realm does not support this
    * operation
   public Enumeration getGroupNames(String user) throws InvalidOperationException, NoSuchUserException {


      Vector<String> vector = new Vector<>();

      // Get the groups from your DB

      return vector.elements();

Having a look in the source code of the Realm class reveals much more things we could do. Most of the tasks are taken charge of by Glassfish’s AppservRealm helper class.

Next task, the ‘LoginModule‘:

package eu.lucubratory.myrealm;




import java.util.Enumeration;
import java.util.List;
import java.util.ArrayList;

 * Completes the abstract AppservPasswordLoginModule base class for password-based login modules.
 * Most login modules receive a username and password from the client (possibly through HTTP
 * BASIC auth, or FORM, or other mechanism) and then make (or delegate) an authentication
 * decision based on this data. The AppservPasswordLoginModule class provides common methods
 * for such password-based login modules.
 * This subclasses need to implement the authenticateUser() method and later call
 * commitUserAuthentication().
public class LoginModule extends AppservPasswordLoginModule {

   public LoginModule() {
      System.out.println("MyRealm LoginModule - Construction");

    * Overrides the authenticateUser() method in AppservPasswordLoginModule
    * Performs authentication of user
    * @throws
   protected void authenticateUser() throws LoginException {

      System.out.println("MyRealm LoginModule authenticateUser(), _username:"+
             _username+", _password:"+_password+", _currentrealm:"+_currentRealm);

      if (!(_currentRealm instanceof MyRealm)) {
          throw new LoginException("Realm not MyRealm. Check 'login.conf'.");
      MyRealm myRealm=(MyRealm)_currentRealm;

      // Authenticate User
      if (!doAuthentication(_username,_password)) {
          //Login failed
          throw new LoginException("MyRealm LoginModule: Login Failed for user "+_username);

      // Login succeeded
      System.out.println("MyRealm LoginModule: Login Succeded for user "+_username);

      // Get group names for the authenticated user from the Realm class
      Enumeration enumeration=null;
      try {
      catch(InvalidOperationException e) {
          throw new LoginException("InvalidOperationException was thrown for getGroupNames() on MyRealm");
      catch(NoSuchUserException e) {
          throw new LoginException("NoSuchUserException was thrown for getGroupNames() on MyRealm");

      // Convert the Enumeration to String[]
      List<String> g=new ArrayList<>();
      while(enumeration!=null && enumeration.hasMoreElements())

      String[] authenticatedGroups=g.toArray(new String[g.size()]);

      // Call commitUserAuthentication with the group names the user belongs to.
      // Note that this method is called after the authentication has succeeded.
      // If authentication failed do not call this method. Global instance field
      // succeeded is set to true by this method.

    * Performs the authentication.
   private boolean doAuthentication(String user, String password) {
      // Implement this.
      return false; // or true :)

The result (in this case) is a JAR file named ‘myrealm-jaas-1.0-SNAPSHOT.jar’. This file has to be copied into the domain’s ‘lib‘ directory: ‘…glassfish-[my domain]lib‘.

The next step is to register the new realm in Glassfish (for our domain) and to associated the ‘LoginModule’ to invoke for authentication within this realm. For this, we need to edit the file ‘..glassfish-[my domain]configlogin.conf‘ and add the following lines at the end:

myRealm {
   eu.lucubratory.myrealm.LoginModule required;

Now the server is ready to be started and we can install the new realm in the Console: ‘Configurations, server-config, Security, Realms‘ – ‘New Realm‘.

Note that all parameters are important. Set ‘Name’ to ‘my-realm’ and ‘Class name’ to  ‘eu.lucubratory.myrealm.MyRealm’. The name is actually what is referenced in ‘web.xml’ and the class name is the completely qualified identification of the realm description class.

Unfortunately, custom realms are not added by Glassfish to the drop-down list, so we need to use the edit box to specify the complete class name.

Next, we add the (additional) property ‘jaas-context’ with the value ‘myRealm’ as specified in ‘login.conf’. As soon as this gets confirmed by hitting the Save button, you get either an error message (hopefully not) or the console output that shows something like:

INFO: Admin Console: Initializing Session Attributes...
INFO: Init MyRealm (-> that's our out.println)
INFO: SEC1115: Realm [myreal-realm] of classtype [eu.lucubratory.myrealm.MyRealm] successfully created.

If the ‘jaas-context’ variable is wrong, Glassfish will throw the following exception when you try to login later: “ Login failed: No LoginModules configured for [Value of jaas-context property]”. This indicates that the server cannot make the link between what is defined in the console and what is in the ‘login.conf’ file.

The last step is to configure our web application to use the new realm. To do so, we add the following in the ‘web.xml’ file.

   <realm-name>my-realm</realm-name>   (name as defined in the console!)

And then, somewhere in a login action (depending on the employed front-end technology)…

void login(HttpServletRequest request) {

The dependency chain to understand is:

  1. HttpServletRequest.login
  2. web.xml <login-config> <realm-name> pointing to
  3. domain setting (domains[my domain]config|domain.xml) realm name pointing to
  4. class describing the realm AND property ‘jaas-context’ parameter pointing TO ‘login.conf’
  5. ‘login.conf’ pointing to the ‘LoginModule’ class to use for authentication

Voila, that’s all… easy, isn’t it :)

5 thoughts on “Custom JAAS Realm for Glassfish 3”

  1. Hi!

    Thanks for your tutorial. I’ve used this steps to make a custom realm in Glassfish 4.0 and this error was displayed:
    WEB9102: Web Login Failed: Login failed: Invalid null input: name…

    To fix, I’ve added a jaas-context property on my auth-realm in domain.xml:


    myRealm {
    eu.lucubratory.myrealm.LoginModule required;

    Now my example is working fine on Glassfish 4.0.

    Best regards,

    1. auth-realm name=”my-realm” classname=”eu.lucubratory.myrealm.MyRealm”
      property name=”jaas-context” value=”myRealm” /property

      1. Could you please write that again? I have a similiar issue and I have no clue what was your solution

Leave a Reply

Your email address will not be published. Required fields are marked *