OK, So I just re-read my post and somehow I in-advertantly deleted the stack trace. However, I have been digging around a little more and was wondering if someone could help me out a little bit. I found a post on the internet that referred to the login.conf file. This file on Glassfish contains the following:

/*  Copyright 2004 Sun Microsystems, Inc.  All rights reserved.    */
/*  SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */

fileRealm {
        com.sun.enterprise.security.auth.login.FileLoginModule required;
};

ldapRealm {
        com.sun.enterprise.security.auth.login.LDAPLoginModule required;
};

solarisRealm {
        com.sun.enterprise.security.auth.login.SolarisLoginModule required;
};

jdbcRealm {
        com.sun.enterprise.security.auth.login.JDBCLoginModule required;
};

When I changed the jaas-conf-name from file to fileRealm the exception changes from No LoginModules configured for file to
No credentials.

The Original Stacktrace

javax.security.auth.login.LoginException: No LoginModules configured for file
        at javax.security.auth.login.LoginContext.init(LoginContext.java:256)
        at javax.security.auth.login.LoginContext.<init>(LoginContext.java:367)
        at javax.security.auth.login.LoginContext.<init>(LoginContext.java:444)
        at org.jboss.seam.security.Identity.getLoginContext(Identity.java:334)
        at org.jboss.seam.security.Identity.authenticate(Identity.java:248)
        at org.jboss.seam.security.Identity.login(Identity.java:205)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        ...

New Stacktrace

13924243 [httpSSLWorkerThread-8080-1] DEBUG org.jboss.seam.security.Identity  - Login failed for: chadws
javax.security.auth.login.LoginException: No credentials.
        at com.sun.appserv.security.AppservPasswordLoginModule.login(AppservPasswordLoginModule.java:155)
        at sun.reflect.GeneratedMethodAccessor168.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
        ...

I guess I am a little confused. When you configure a JAAS Realm (in Glassfish) you give that realm a name, a Class Name, a JAAS Context, and then the configuration parameters for that configuration. The JAAS contexts, represented by the entries in the login.conf file, are not specific to a single connection, but rather are shared by all connections using the same login modules.

How does Seam handle the configuration if you specify the JAASContext name and not the realm name. In otherwords ldapRealm in the login.conf file knows about the login module, but not the configuration (host, base dn, etc). Do I need to create a completely separate realm and create a context specifically for that realm with the same name.

I'm still lost, but getting closer!

Ok, So I figured out that SEAM does not use the servers JAAS configuration, but rather you must specify all of the properties in the domains login.conf file. After specifying the following I am now able to log in using SEAM.

testLDAP {
   com.sun.security.auth.module.LdapLoginModule REQUIRED
   userProvider="ldap://loader1.topeka.k12.ks.us/ou=staff,ou=users,o=webservices"
   userFilter="(&(cn={USERNAME})(objectClass=inetOrgPerson))"
   useSSL=false
   debug=true;
};

Having this much completed I have yet to figure out how to get the login module to return the roles for the user. Does anyone know how I specify what roles need checked or how to get the roles returned for a user who logs in?

First the question, what is the proper method of fixing the following problem? I can extend the JAAS login module to consult the callback or extend Identity to add the custom private credential to the identity before calling the authentication code?

The issue, After much digging and running through stack traces I found what I believe to be the problem. The AppservPasswordLoginModule does not use the callbackHandler, but rather expects to find the password credential in a privateCredential that is specific to the glassfish application server. Here is the javadoc:

Source Repository Link

/**
 * Perform login.
 *
 * <P>The callback handler is used to obtain authentication info
 * for the subject and a login is attempted. This PasswordLoginModule
 * expects to find a PasswordCredential in the private credentials
 * of the Subject. If not present the login fails. The callback
 * handler is ignored as it is not really relevant on the server side.
 * Finally, the authenticateUser() method is invoked.
 *
 * @returns true if login succeeds, otherwise an exception is thrown.
 * @throws LoginException Thrown if login failed, or on other problems.
 *
 */

Also, does anyone know why they would have chosen to ignore the callback? Are there security issues with having the module check the callback for the password?