j_security_check failing to authenticate users in JSF application

[Jay Tai]

I'm trying to develop a user authentication system using JSF, JPA and j_security_check in GlassFish4. I'm able to create and populate the USER and GROUP tables using domain entity classes, with the following schema in mySql:


+----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| username | varchar(255) | NO | PRI | | |
| password | varchar(255) | YES | | NULL | |
+----------+--------------+------+-----+---------+-------+


-> ;
+-----------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------+--------------+------+-----+---------+-------+
| groupname | varchar(20) | NO | PRI | | |
| username | varchar(255) | YES | | NULL | |
+-----------+--------------+------+-----+---------+-------+

When it comes to logging in I am always directed to the error page even though I'm entering the correct username and password to access the 'admin' folder. This tells me that Login might not even be querying the DB.

One warning which caught my eye when trying to log in is:

INFO:   JACC Policy Provider: Failed Permission Check, context(UserAdmin2/UserAdmin2)- permission(("javax.security.jacc.WebUserDataPermission" "/faces/admin/adminindex.xhtml" "GET")

Not sure if this suggests that j_security_check is already firing a query before I load the Login page or if my configurations are just plain wrong so that the j_security_check isn't even talking to the DB. Any guidance on this and configuring j_security_check in JSF is much appreciated.


The Login.xhtml looks like:

 <form method="POST" action="j_security_check">
            <h:panelGrid columns="2">
                <h:outputLabel value="User Name"/>
                <input type="text" name="j_username"/>
                <h:outputLabel value="Password"/>
                <input type="password" name="j_password"/>                    
                <input type="submit" value="Login"/>                    

            </h:panelGrid>
        </form>

Security constraints on web.xml:

 <security-constraint>
        <display-name>AdminConstraint</display-name>
        <web-resource-collection>
            <web-resource-name>ADMINISTRATOR</web-resource-name>
            <description/>
            <url-pattern>/faces/admin/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description/>
            <role-name>ADMINISTRATOR</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description/>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <security-constraint>
        <display-name>UserConstraint</display-name>
        <web-resource-collection>
            <web-resource-name>USER</web-resource-name>
            <description/>
            <url-pattern>/faces/users/*</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description/>
            <role-name>ADMINISTRATOR</role-name>
            <role-name>USER</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description/>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
...
<login-config>
        <auth-method>FORM</auth-method>
        <realm-name>jdbc-realm</realm-name>
        <form-login-config>
            <form-login-page>/faces/Login.xhtml</form-login-page>
            <form-error-page>/faces/error.xhtml</form-error-page>
        </form-login-config>
    </login-config>

glassfish-resources.xml:

<resources>
  <jdbc-resource enabled="true" jndi-name="jdbc/testDatasource" object-type="user" pool-name="TestconnectionPool">
    <description/>
  </jdbc-resource>
  <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="TestconnectionPool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
    <property name="URL" value="jdbc:mysql://localhost:3306/userschema?zeroDateTimeBehavior=convertToNull"/>
    <property name="User" value="root"/>
    <property name="Password" value="***"/>
  </jdbc-connection-pool>
</resources>

GlassFish 4 realm configuration

realm name: jdbc-realm
JAAS Context: jdbcRealm
JNDI: jdbc/testDatasource
User Table: users
User Name Column: username
Password Column: password
Group Table: groups
Group Table User Name Col: username
Group Name Col: groupname
Password Encryption: SHA-256
Charset: UTF-8
...rest all default values

[Tim Holloway]

1. You are aware, I hope, that when using the J2EE container security login that the user does NOT request the login page as an explicit URL. It's presented automatically when a secured URL request is made and has no URL of its own. In other words: "http://www.myserver.com:8080/faces/Login.jsf" will not function as a valid request.

2. Server-presented pages such as the login/loginfail, error pages, and similar constructs often don't work properly in frameworks such as JSF that depend on a dispatcher servlet. Not all versions of all servers will route internal requests through the servlet, and if that isn't done, then the JSF lifecycle won't be applied. In any event, container login code is not part of the application, it's part of the webapp server, which doesn't use JSF. And in the case of Tomcat, JSF isn't integrated into the server anyway.

It's also a security risk to put rich content on a login page. My login pages are generally stark html or vanilla JSPs. They aren't provided with menus that could potentially hijack the authentication process and keep the CSS and javascript to a minimum. I save the friendly stuff for people who've passed authentication.

[Jay Tai]

1. You are aware, I hope, that when using the J2EE container security login that the user does NOT request the login page as an explicit URL. It's presented automatically when a secured URL request is made and has no URL of its own. In other words: "http://www.myserver.com:8080/faces/Login.jsf" will not function as a valid request.

I'm aware that the j_security_check has almost nothing to do with the JSF framework and I'm getting the login form trying to access the admin folder "http://www.myserver.com:8080/faces/admin/adminindex.xhtml"

My login pages are generally stark html or vanilla JSPs

I replaced my login and error forms with a plain html documents without any jsf tags but it did not solve my problem. I"m still re-directed to the error page even when typing the correct UN and PW for admin user.

This looks like a j_security_check servlet issue where the database is simply not being checked for the user credentials? Could the JPA part of the application (where I create users and look up the list of users for administration purposes) be conflicting with j_security_check? The JPA works fine and I'm able to 'administer' user accounts, creating users, creating groups, listing users, groups, etc.

[Tim Holloway]

OK. Just had to cover the basics. When there's too much detail in the original question, I tend to take the easy way out and make sure that whoever's asking knows the fundamentals.

There isn't a "j_security_check" servlet as such. j_security_check is an indicator to the server's Realm management code that the authentication manager posted a login/loginfail form and this is the client's response to that form. That's why a "http://www.myserver.com:8080/j_security_check" URL request will fail. It's needed because the user could have simply made some other request that aborts the login, and the only way to tell would be by the incoming data.

Your noted error (INFO) message actually sounds like a violation of the JVM's configured security rules. Meaning that even if you have your server authentication set up perfectly, the JVM may be offended. Are you overriding its standard security policies?

I'm a little bit at a loss here, since GlassFish and I never became very good friends. I can tell you definitively that in the Tomcat server the datasource for application database requests will not conflict with the use of a database-related security Realm. Although I believe that their standard Realm module collection includes a Realm that will allow the Realm and Datasource to use a common definition so that you don't have to enter the URL and credentials twice in the configuration if both the connection pool and realm are sharing the same database.

You might want to present your question to the GlassFish forum. Make up a basic app with a secured URL, login/loginfail page and security definitions, make it fail, then report what you've got to them.

If you can get that much working, the only difference in JSF is that you'd want to use the "redirect" option when navigating to secured Views, since the container security looks at URLs, not underlying resources (xhtml, etc.) and without the "redirect" option, the URLs tend to lag the view resources, thus presenting potential security issues.

[Jaikiran Pai]

My guess based on that log message is that the authorization seems to be failing. Perhaps the authentication is passing. Have you checked that the query returns back the correct role(s) and it satisfies the role requirement noted in the web.xml for that resource?

By the way, you might want to enable finer level of logging for some appropriate glassfish packages to see what's going on. I've added this thread to the GlassFish forum too.

[Jay Tai]

Have you checked that the query returns back the correct role(s) and it satisfies the role requirement noted in the web.xml for that resource?

Yes I've executed selected queries from within the DB console and I'm getting values back for the roles and users. I've also set up a JSF/ JPA admin application and I'm successfully able to manipulate DB values from there too.

I think your advice about fine logging makes sense and I'll be trying that next . Thank you!

[Jay Tai]

Took me a while to configure the GlassFish logging, which obviously gave a very long log when i set the javax.enterprise.system.core=FINEST. Some key parts of that log are:

FINE:   [Web-Security] Policy Context ID was: UserAdmin2/UserAdmin2
FINE:   [Web-Security] Codesource with Web URL: file:/UserAdmin2/UserAdmin2
FINE:   [Web-Security] Checking Web Permission with Principals : null
FINE:   [Web-Security] Web Permission = ("javax.security.jacc.WebUserDataPermission" "/faces/admin/adminindex.xhtml" "GET")
FINE:   JACC Policy Provider, failed Permission Check at :
java.lang.Exception
	at com.sun.enterprise.security.provider.BasePolicyWrapper.doImplies(BasePolicyWrapper.java:408)
	at com.sun.enterprise.security.provider.BasePolicyWrapper.implies(BasePolicyWrapper.java:250)
	at com.sun.enterprise.security.web.integration.WebSecurityManager.checkPermissionWithoutCache(WebSecurityManager.java:416)
	at com.sun.enterprise.security.web.integration.WebSecurityManager.checkPermission(WebSecurityManager.java:350)
	at com.sun.enterprise.security.web.integration.WebSecurityManager.hasUserDataPermission(WebSecurityManager.java:553)
.............
............
INFO:   JACC Policy Provider: Failed Permission Check, context(UserAdmin2/UserAdmin2)- permission(("javax.security.jacc.WebUserDataPermission" "/faces/admin/adminindex.xhtml" "GET"))
FINEST:   JACC Policy Provider: PolicyWrapper.getPermissions(d), context (UserAdmin2/UserAdmin2) permissions: java.security.Permissions@7ed1f882 (
........
........
FINE:   Domain that failed(ProtectionDomain  (file:/UserAdmin2/UserAdmin2 <no signer certificates>)
 null
 <no principals>
 java.security.Permissions@b125fda (
.......
.......
FINEST:   JACC Policy Provider: PolicyWrapper.implies, context (UserAdmin2/UserAdmin2)- result was(false) permission (("javax.security.jacc.WebUserDataPermission" "/faces/admin/adminindex.xhtml" "GET"))
FINE:   [Web-Security] hasUserDataPermission perm: ("javax.security.jacc.WebUserDataPermission" "/faces/admin/adminindex.xhtml" "GET")
FINE:   [Web-Security] hasUserDataPermission isGranted: false
FINE:   [Web-Security] Policy Context ID was: UserAdmin2/UserAdmin2
FINE:   Getting private key for alias:s1as
FINE:   Getting certificate chain

The last few lines above indicate that the permission is failing before the login form actually appears, which tells me that this could be something wrong with the JDBCRealm config in the glassfish admin console?

Also does the following message suggest that the security check might be looking for a FILEREALM instead of a JDBCREALM?

FINE: Domain that failed(ProtectionDomain (file:/UserAdmin2/UserAdmin2 <no signer certificates>)

[Jay Tai]

I have an update but not a solution. In the GF Admin console Security tab, there is a [Default Realm] setting which was set to 'file-realm'. I set this to 'jdbc-realm', which produced a slightly different error log from my prior post:

FINE:   [Web-Security] Setting Policy Context ID: old = null ctxID = UserAdmin2/UserAdmin2
FINE:   [Web-Security] Codesource with Web URL: file:/UserAdmin2/UserAdmin2
FINE:   [Web-Security] Checking Web Permission with Principals : null
FINE:   [Web-Security] Web Permission = ("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET")
FINEST:   JACC Policy Provider: PolicyWrapper.implies, context (UserAdmin2/UserAdmin2)- result was(false) permission (("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET"))
FINE:   [Web-Security] hasResource isGranted: false
FINE:   [Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET")
FINEST:   Processing login with credentials of type: class com.sun.enterprise.security.auth.login.common.PasswordCredential
FINE:   Logging in user [test] into realm: jdbc-realm using JAAS module: jdbcRealm
FINE:   Login module initialized: class com.sun.enterprise.security.ee.auth.login.JDBCLoginModule
FINE:   JAAS authentication aborted.
FINEST:   doPasswordLogin fails
javax.security.auth.login.LoginException: Security Exception
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:870)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
	at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:383)

I'm thinking that the DB user, password and group tables are being read but something is preventing the authentication OR authorization process from completing. Just to test if the tables are being read I set the tables to a dummy value (jdbcrealm.users, jdbdrealm.groups). I got a 'table does not exist' error in the log, which is no longer there when i simply refer to the tables as 'users' and 'groups'.

[Tim Holloway]

The default Realm is simply the Realm used when a webapp didn't have a specific Realm configured for that application.

Here is the abstract form of the JDBC Realm's authenticate method, invoked when you are using the JDBC Realm and a j_security_check submission is being processed by the server:

/**
 * Authenticate user using credentials from client
 *
 * @param userId The j_userid from the login dialog or form
 * @param password The j_password from the login dialog or form
 * @return true to indicate that credentials are valid and user login session should be constructed,
 *     false if authenticate fails and the loginfail page or rejection dialog should be displayed.
 */

public boolean authenticate(String userId, String password) {
    final String SQL_COMMAND = "SELECT COUNT(*) FROM USERTABLE WHERE USERID=? AND PASSWORD=?";
    PreparedStatement ps = getConnection().prepareStatement(SQL_COMMAND);
    ps.setParameter(1, userId);
    ps.setParameter(2, password);
    Resultset rs = ps.executeQuery();
    int authentic = rs.getInt(1);
    if ( authentic != 0) {
          return true;
    } else {
          return false;
    }
}

Actual code will plug in the appropriate table and field names to the SQL, and may construct a UserPrincipal object, but this is the essence. Note that the SQL never actually exposes the database copy of the userID or password, simply verifies that they match. Makes it harder for hackers to retrieve and exploit secret information.

The important thing to note is that this is a boolean function, not something that throws an exception like your stacktrace indicates. I think that there should be further information in your stack trace to indicate why the exception was thrown.

There are 2 messages in your log that bear investigating:

FINE: [Web-Security] Checking Web Permission with Principals : null

While it may simply mean that the user isn't logged in yet (UserPrincipal is still null), it might also be talking about the security under which the actual security check is being conducted.

The second message:

FINE: [Web-Security] hasResource isGranted: false

Is harder to comprehend.

[Jay Tai]

There are 2 messages in your log that bear investigating:

FINE: [Web-Security] Checking Web Permission with Principals : null

I can neither get more information on these errors from the stack trace nor Am I finding much online. I have set the logging to FINEST so isn't this the most granular level of logging?


After trying to configure the connection pool in the GlassFish admin console (using exactly the same parameters as specified in the GlassFish documentation), I am getting the following trace:

FINE:   [Web-Security] hasResource isGranted: false
FINE:   [Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET")
FINEST:   Processing login with credentials of type: class com.sun.enterprise.security.auth.login.common.PasswordCredential
FINE:   Logging in user [test] into realm: jdbc-realm using JAAS module: jdbcRealm
FINE:   Login module initialized: class com.sun.enterprise.security.ee.auth.login.JDBCLoginModule
FINE:   JAAS authentication aborted.
FINEST:   doPasswordLogin fails
javax.security.auth.login.LoginException: Security Exception
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:870)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594)

Now If I remove the Transport Gaurantee setting from my web.xml, I get the following stack trace (where the Principals permission is still null but the hasUserDataPermission is true). This leads me to suspect that the prior trace was due to an SSL certificate error?

FINE:   [Web-Security] hasUserDataPermission isGranted: true
FINE:   [Web-Security] Policy Context ID was: UserAdmin2/UserAdmin2
FINE:   [Web-Security] Generating a protection domain for Permission check.
FINE:   [Web-Security] Codesource with Web URL: file:/UserAdmin2/UserAdmin2
FINE:   [Web-Security] Checking Web Permission with Principals : null
FINE:   [Web-Security] Web Permission = ("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET")
FINEST:   JACC Policy Provider: PolicyWrapper.implies, context (UserAdmin2/UserAdmin2)- result was(false) permission (("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET"))
FINE:   [Web-Security] hasResource isGranted: false
FINE:   [Web-Security] hasResource perm: ("javax.security.jacc.WebResourcePermission" "/faces/admin/adminindex.xhtml" "GET")
FINE:   [Web-Security] Policy Context ID was: UserAdmin2/UserAdmin2
FINE:   [Web-Security] hasUserDataPermission perm: ("javax.security.jacc.WebUserDataPermission" "/faces/login.html" "GET")
FINE:   [Web-Security] hasUserDataPermission isGranted: true

I have to two questions while I continue researching possible causes and solutions?

1) In Netbeans I set the 'Confidental' Transport Gaurantee in the web.xml which activates SSL (https) and throws the usual certificate error before displaying the login page. Could this be responsible for the failed permission errors in the stack trace?

2) Do I have to create the connection pool in the GlassFish Admin console or is it sufficient to create a JDBC resource file and conection pool, as well as PersistenceContextUnit in Netbeans and deploy this in the application?

I know that this resource file created in Netbeans is talking to the DB because I'm able to create users and roles in the admin part of my application

[Tim Holloway]

I can neither get more information on these errors from the stack trace nor Am I finding much online. I have set the logging to FINEST so isn't this the most granular level of logging?

Nah. The most granular level is to yank down a copy of the source code and put it under a debugger. Which is probably what I'd be doing if I was stuck for so long on something like that. One of the advantages of using an open-source product. Especially now that closed-source paid product support is so often worthless.

You will have problems if you don't have your certs set up properly and you attempt to use secure transport. And a login screen should ALWAYS be secured (obviously!) It' even possible, since this is a server function, that the server forces secure transport for the login screens, regardless of what the app itself says. Whether or not that's part of your problem, I can't say. Ideally, there would be a more obvious message in cases like that. I'm not sure if by "the usual certificate error" you mean a warning on the client or an actual failure to access the cert/cert chain from the server's certificate store. Client-side warnings can usually be ignored for testing purposes. Heck, my local public libary has warnings in production (cert expired long ago). Then again they outsourced their emailing to an outfit in Belgium that cannot do basic HTML right. I've yet to actually be able to read an email from my library on any device I own. Maybe IE can handle it, but I don't do IE.

I'm not totally sure I understand question #2, but if it's what I think you're asking, the GlassFish Admin console sets deployment options, but what in J2EE terms is known as the server-specific deployment file can also do so. If that's what your "JDBC Resource file" is. The other deployment file (server-independent deployment file) is the webapp's WEB-INF/web.xml file, incidentally.

[Jay Tai]

You gotta love creative outsourcing that creates colorful problems for today's practical solutions!

Looks like my problem is related to a JNDI naming exception. I set the debugger for the logincontext in the JVM option of the GlassFish domain.xml and got the following trace:

FINE:   Cannot validate user
javax.security.auth.login.LoginException: Unable to connect to datasource jdbc/securityDataSource for database user null.
	at com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm.getConnection(JDBCRealm.java:585)
	at com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm.isUserValid(JDBCRealm.java:408)
	at com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm.authenticate(JDBCRealm.java:324)
	at com.sun.enterprise.security.ee.auth.login.JDBCLoginModule.authenticate(JDBCLoginModule.java:78)
	at com.sun.enterprise.security.auth.login.PasswordLoginModule.authenticateUser(PasswordLoginModule.java:116)
	at com.sun.enterprise.security.BasePasswordLoginModule.login(BasePasswordLoginModule.java:146)
	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Caused by: javax.naming.NamingException: Lookup failed for 'jdbc/securityDataSource' in SerialContext[myEnv={com.sun.enterprise.connectors.jndisuffix=__nontx, java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: securityDataSource not found]
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)
	at javax.naming.InitialContext.lookup(InitialContext.java:411)



Caused by: javax.naming.NameNotFoundException: securityDataSource not found
	at com.sun.enterprise.naming.impl.TransientContext.doLookup(TransientContext.java:237)
	at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:204)
	at com.sun.enterprise.naming.impl.TransientContext.lookup(TransientContext.java:208)
	at com.sun.enterprise.naming.impl.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:66)
	at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:114)
	at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:478)


FINE:   JAAS authentication aborted.
SEVERE:   [LoginContext]: original security exception with detail msg replaced by new exception with empty detail msg
SEVERE:   [LoginContext]: original security exception: com.sun.enterprise.security.auth.login.common.LoginException: Failed jdbc login for test.
FINEST:   doPasswordLogin fails
javax.security.auth.login.LoginException: Security Exception
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:870)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)

So I'm checking my xml config files are correct starting with glassfish-resources.xml (this is supposed to store the config information for the JDBC resource and connection pool AND YES THANKS FOR ANSWERING QUESTION 2):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Resource Definitions//EN" "http://glassfish.org/dtds/glassfish-resources_1_5.dtd">
<resources>
  <jdbc-resource enabled="true" jndi-name="jdbc/securityDatasource" object-type="user" pool-name="securityDataSourcePool">
    <description/>
  </jdbc-resource>
  <jdbc-connection-pool allow-non-component-callers="false" associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" connection-validation-method="auto-commit" datasource-classname="com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" is-isolation-level-guaranteed="true" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="false" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="securityDataSourcePool" non-transactional-connections="false" pool-resize-quantity="2" res-type="javax.sql.ConnectionPoolDataSource" statement-timeout-in-seconds="-1" steady-pool-size="8" validate-atmost-once-period-in-seconds="0" wrap-jdbc-objects="false">
    <property name="URL" value="jdbc:mysql://localhost:3306/jdbcrealm?zeroDateTimeBehavior=convertToNull"/>
    <property name="User" value="root"/>
    <property name="Password" value="manaar"/>
  </jdbc-connection-pool>
</resources>

Here I'm not sure of the conection pool name (securityDataSourcePool) should just be called securityDataSource and this is the reason GF is unable to look up the JNDI?

Then the glassfish deployment descriptor glassfish-web.xml only contains role mappings:

<glassfish-web-app error-url="">
  <security-role-mapping>
    <role-name>ADMINISTRATOR</role-name>
    <group-name>ADMINISTRATOR</group-name>
  </security-role-mapping>
  <security-role-mapping>
    <role-name>USER</role-name>
    <group-name>ADMINISTRATOR</group-name>
    <group-name>USER</group-name>
  </security-role-mapping>
  <class-loader delegate="true"/>
  <jsp-config>
    <property name="keepgenerated" value="true">
      <description>Keep a copy of the generated servlet class' java code.</description>
    </property>
  </jsp-config>
</glassfish-web-app>

web.xml seems like it correctly refers to the correct JDBCRealm

<login-config>
        <auth-method>FORM</auth-method>
        <realm-name>jdbcrealm</realm-name>
        <form-login-config>

The realm configurations in the GF admin console are:

realm name: jdbcrealm
JAAS Contetx: jdbcRealm
JNDI: jdbc/securityDataSource
User Table: users
Username column: username
Password column: password
Group Table: groups
Group Table UN column: username
Group name col: groupname
password encryption algorithm: none

So far I can't see the cause of the JNDI conflict from these files but i'm sure I'm missing something

[Tim Holloway]

The name "securityDataSourcePool" is what connects the jdbc-resource to the jdbc-connection-pool so that's fine.

However, I do have doubts about the jdbc-connection-pool definition. It defines values for parameters "User", "Password" and "URL". In most systems, those would be lower-case names, and Java stuff is almost invariably case-sensitive, so unless the GlassFish connection pool construction is different, that would mean that effectively you would have defined a pool to nowhere with no security credentials. The only reason I'm not more assertive about that is that I'm understanding that the original copy of that file was constructed by the GlassFish admin GUI, which is supposed to know what's right.

There's a fourth parameter that database connections normally require and it's missing. That's the fully-qualified classname of the JDBC driver that must be used. It's important since most J2EE servers don't come with JDBC drivers wired into them, and even if they did, a lot of databases have more than one driver, either because they have difference performance features or they come from third parties or both.

Once again, hitting the obvious, the driver must be installed in GlassFish itself and NOT in the WAR for this to work properly. People do sometimes make that mistake.

[Jay Tai]

OK one odd thing I noticed was the pool settings were duplicated:

User
Password
URL
user
password
url

I deleted the Uppercase values, flushed the connection pool, pinged the connection, both successful

Ensured the mySql driver was installed in the GF domain/domain1/lib

Undeployed the app and stopped the server

Adjusted the resource file so only small case letters are there

Restarted the server

SAME ERROR!

I also read somewhere that using generic names like users and groups for the tables causes conflicts. I'm going to try and change those but can something like the table names cause a JNDI conflict? Isn't that more likely to cause a sql exception?

[Tim Holloway]

Although details aren't clear, I think the JNDI error is coming from the fact that the connection pool isn't being created, hence there's nothing to store under the selected JNDI subtree, causing failure when an attempt is made to retrieve what isn't there.

You didn't mention providing a driver class, and I'm very doubtful that GlassFish can reliably infer what class to use - assuming it wants to infer anything at all.

I should have bounced this to the GlassFish forum, because what we really need is some input from people who regularly configure GlassFish. So I'm going to move this topic over there.

[Jay Tai]

Good idea. When posting this I couldn't decide if it was a GF or JSF problem. I don't follow why GF has to infer anything about the driver. When creating the jdbc resource and connection pool I am given an option to use an existing DB connection which is a mySql schema. When i checked the GF domain/domain1/lib directory after creating the connection pool I saw the mySql Connector J drive in there. Where would I specify the right driver to use and doesn't the mySql driver in the domain directory mean that GF has inferred mySql is the default?

[Tim Holloway]

Usually, the driverClass is one of the 4 parameters that define a connection or connection pool. There's no guaranteed way to determine the "right" class, however. Some driver jars contain multiple drivers sharing common code, especially those that support both regular and extended transactions. Some drivers you don't WANT pulled in by default. A couple of years ago, Microsoft's SQL Server JDBC driver did a really botch-up job of handling transactions and I had to use a third-party SQL Server driver (open-source from sourceforge.net) to make the app functional. The Microsoft driver has been fixed since then, but at the time, it was impossible.

So that's why red lights flash when I don't see an explicit driver class specified as part of the pool definition.

[Jay Tai]

I totally see where you're coming from but I can't find where I would have to put the driver. When creating the resource and connection pool there doesn't seem to be any option to specify the driver unless I add the driver as a property. I hesitated to do that because j_security_check seems to be such a fussy 'framework' in terms of keeping to best practices. But I seem to have gone 'by the book' so please let me know where I should define the driver and I'll see if this solves the problem.

In the GF Admin console under Connection Pool there is an option to add the driver classname, but it's greyed out and I can't enter any values there!

Thank you!

[Tim Holloway]

The driverClass is normally one of the parameters provided along with the database URL, user ID and password.

You aren't having problems with container-managed security as far as I can tell, you're having problems with your database connection pool. The security issues because you're using a Realm that requires a proper database connection, so if you can fix that, likely the security issues will clear up.

If Glassfish is like Tomcat, there should be a Realm that can get the userid/password and userid/roles from a flat or XML file. That's often a useful way to test security when you don't have the ability to connect to the production security framework. Since Realms are plug-compatible, no application changes are required. So you might want to try that while we're waiting for someone to reveal why you appear to have basic database issues.

[Jay Tai]

I think Tomcat is a bit simpler and more lightweight but I have to use GF for this project.

On GF I see a realm defined in the web.xml and the glassfish-resources.xml and a reference to the DataSource in the persistence.xml where I am able to run JPQL queries. Apart from that I don't see anywhere where I can unit test the realm. I'll keep looking.

[Tim Holloway]

Tomcat is simpler. But in the matter of container security, it's fully-compliant. What I was getting at was that since Tomcat has a simple Realm that's useful for testing and other lightweight security needs, it wouldn't surprise me if Glassfish did too. In fact - just a minute - http://docs.oracle.com/cd/E18930_01/html/821-2435/ggkuk.html - it's called the File Realm, and it's the default.

Glassfish actually calls them Authentication Realms or Security Domains. Hopefully the term "Authentication Realm" isn't literal, since a Realm typically provides both Authentication (login) and Authorization (role checking). A quick scan of the docs would give the impression that you actually needed to map roles to user IDs in the deployment descriptor, but I hope that isn't the only way, since it would quickly become unmanageable. Better to define the user role mappings in a database, LDAP directory or other large-capacity external storage. And again, if Tomcat does it (and it does), I'd expect Glassfish to be able to do so.

[Jay Tai]

I see what you mean now. I've actually used the file realm in another application. I can test this in the file realm but I suspect, as you said, my problem is probably with the connection pool. Here is another problem I came across with regards to the driver for the connection pool. When you create a resource and connection pool in Netbeans you don't have the option to specify the driver. The pool just uses an existing connection with an already specified driver. If you create a pool from the GF admin console then try to create a resource from the IDE (Netbeans), the connection pool created from GF admin console (after restarting the server) is not detected by the IDE.

So my first question is, how do you create a connection pool and jdbc resource where the driver class can be specified?

[Tim Holloway]

NetBeans isn't going to be around when the server runs in production. You need to determine how to define the connection pool strictly via Glassfish.

[Jay Tai]

True but I still need to get the GF admin console setting recognized by the Netbeans config files in order to deploy the application correctly. Right?

[Tim Holloway]

Only if you are dependent on NetBeans to do your deploying for you. An IDE is supposed to help you develop, not be an essential part of the production process.

[Jay Tai]

OK so I followed your advice and created the connection pool and resource strictly in the GF server, instead of creating 'portable' resource and CP configuration files in Netbeans. I'm still using web.xml to refer to the jdbc-realm. Doesn't look like I'm getting a NameNotFoundException anymore. Instead I'm getting a more mysterious error:

SEVERE:   [LoginContext]: original security exception with detail msg replaced by new exception with empty detail msg
FINE:   JAAS authentication aborted.
SEVERE:   [LoginContext]: original security exception: com.sun.enterprise.security.auth.login.common.LoginException: Failed jdbc login for test.
FINEST:   doPasswordLogin fails
javax.security.auth.login.LoginException: Security Exception
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:870)
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698)
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695)
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594)
...

Caused by: java.lang.SecurityException
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:871)
	... 38 more

SEVERE:   [LoginContext]: login REQUIRED failure
WARNING:   WEB9102: Web Login Failed: com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Security Exception
FINE:   [Web-Security] Policy Context ID was: userMaven/userMaven
SEVERE:   [LoginContext]: abort ignored

This suggests that the Connection Pool might now be getting read by the application. I'm suspecting that the error might be a result of the user and role mappings. When I got rid of the Netbeans configuration files and created everything on the actual server, it also meant that I had to get rid of the glassfish-web.xml descriptor, since that file depends on the other configuration files. So should I be mapping the users and roles from web.xml? Could this be the cause f the above error?

[Tim Holloway]

web.xml is the container independent deployment descriptor. It defines the URL patterns and roles and how they interrelate.

The other half of that equation is the container dependent deployment descriptor. In Tomcat, that would be the Context file. I'm not sure what it is in Glassfish, and I keep hoping someone who knows will jump in and help.

You don't map users and their assigned roles or even database tables and columns in web.xml because the Realm is defined to the Container (Glassfish), not to the webapp. By keeping those details out of web.xml, the Realm can be changed - say from jdbc to a file or LDAP database without requiring any changes in the webapp itself (including web.xml).

[Jay Tai]

I'll consult the GF documentation but I recall glassfish-web.xml is where the user and role mapping took place previously and it automatically detects the security roles from web.xml but you need to create the mapping relationship in that file. I don't see any reason why I can't keep that file even if I'm not creating jdbc resources within the application. Assuming glassfish-web is the 'dependent' file, could excluding this be the cause of the exception in my last post?

[Jay Tai]

Update - hearing about various rumours of GF 4 having bugs and problems with connection pools, I donwgraded to GF 3. I followed the GF documentation and online resources, re-created all my resources (including connection pool), placed the mySql driver in the gf/domains/domain1/lib. I got the below error, changed the location to gf/lib, error, changed location to gf/domains/domain1/databases. The below error is still there:

INFO: Admin Console: Initializing Session Attributes...
SEVERE: RAR5099 : Wrong class name or classpath for Datasource Object 
java.lang.ClassNotFoundException: com.mysql.jdbc.jdbc2.optional.MysqlRealmTestTwoConnectionPoolDataSource
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:270)
	at com.sun.gjc.common.DataSourceObjectBuilder.getDataSourceObject(DataSourceObjectBuilder.java:285)
	at com.sun.gjc.common.DataSourceObjectBuilder.constructDataSourceObject(DataSourceObjectBuilder.java:114)
	at com.sun.gjc.spi.ManagedConnectionFactory.getDataSource(ManagedConnectionFactory.java:1307)
	at com.sun.gjc.spi.DSManagedConnectionFactory.getDataSource(DSManagedConnectionFactory.java:163)
	at com.sun.gjc.spi.DSManagedConnectionFactory.createManagedConnection(DSManagedConnectionFactory.java:102)
	at com.sun.enterprise.connectors.service.ConnectorConnectionPoolAdminServiceImpl.getUnpooledConnection(ConnectorConnectionPoolAdminServiceImpl.java:697)
	...

WARNING: RAR8054: Exception while creating an unpooled [test] connection for pool [ realmTestTwoPool ], Class name is wrong or classpath is not set for : com.mysql.jdbc.jdbc2.optional.MysqlRealmTestTwoConnectionPoolDataSource
SEVERE: RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/resources/ping-connection-pool.json'; attrs = '{id=realmTestTwoPool}'
WARNING: RAR8023: Flush Connection Pool did not happen as pool - realmTestTwoPool is not initialized
SEVERE: RestResponse.getResponse() gives FAILURE.  endpoint = 'http://localhost:4848/management/domain/resources/flush-connection-pool.json'; attrs = '{id=realmTestTwoPool}'

The ping fails too on GF 3 with the same error, but ping works on GF4. Looking online, GF connection pooling seems to be riddled with problems!