Tips for setting up JNDIRealm

[Chris Maloof]

I'm using securityfilter with JNDIRealm in my application.  Mostly it works fine, except that sometimes the first login attempt fails for no apparent reason.  The problem looks to be

which was fixed in Tomcat 5.

Now, I'm using Tomcat 6, but in setting up securityfilter, I'd put the old catalina.jar file from the securityfilter lib into my own WEB-INF/lib directory.  It seems to be from some Tomcat 4 version, and its Realms are compatible with securityfilter.  But its inclusion is resurrecting the old JNDIRealm bug.  (Is the catalina version mismatch with the container liable to cause other problems?  If not, it seems like a handy trick.)

Unfortunately, the Tomcat 6 catalina.jar file won't work here; it doesn't get along with securityfilter anymore, for reasons discussed at  and  .

My solution was to download and recompile the Tomcat 4.1 source with the bug fixed - the first link explains the code change needed.  This appears to do the trick.

  : https://issues.apache.org/bugzilla/show_bug.cgi?id=33774
  : http://marc.info/?t=121751323100003&r=1&w=2
  : http://markmail.org/message/dowa54il64wdupxq

[Christopher Schultz]

Correct: securityfilter was originally written to work with the Tomcat 4 Realms. In the intervening versions, changes within Tomcat have been made that break the interoperability between securityfilter and Tomcat's Realm implementations.

Even when the API is compatible (for instance, with Tomcat 5.0 or 5.5, I think), catalina.jar now has dependencies on the actual runtime instances of Tomcat's classes and so it's not as simple as dropping catalina.jar into your webapp's WEB-INF/lib directory, anymore.

The good news is that you can always implement your own Realm implementations by "borrowing" code from Tomcat if you wish.

-chris

[Chris Allan]

I have a situation in which I also don't want to revert back to the old Tomcat 4 catalina.jar.  I Include the following in my context due to a big with Internet Explorer and caching over secure connections:

<Valve className="org.apache.catalina.authenticator.FormAuthenticator" securePagesWithPragma="false" />
    <Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" securePagesWithPragma="false" />

However when adding the tomcat4 catalina.jar to my webapp this results in the following error when starting up tomcat:
java.lang.NullPointerException
        at org.apache.catalina.realm.RealmBase.init(RealmBase.java:1374)
        at org.apache.catalina.realm.RealmBase.start(RealmBase.java:1033)
        at org.apache.catalina.realm.JDBCRealm.start(JDBCRealm.java:766)
        at org.securityfilter.realm.catalina.CatalinaRealmAdapter.setRealm(CatalinaRealmAdapter.java:79)

and when I try to log in to my app it freezes on j_security_check and gives the following error:
SEVERE: An exception or error occurred in the container during the request processing
java.lang.NullPointerException
        at org.apache.catalina.authenticator.FormAuthenticator.forwardToErrorPage(FormAuthenticator.java:333)
        at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:260)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:417)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)

So, would a custom Realm implementation fix this? I am currently using JBDCRealm. If anyone has a realm implementation which I can use with tomcat 5.5 that would be reaaaally helpfull! Or any other suggestions are very welcome!

Cheers,

Chris

[Christopher Schultz]

I wouldn't be surprised if Tomcat uses the WebappClassLoader for <Valve> definitions within your <Context>, so what's happening is that it's trying to use the classes in WEB-INF/lib/catalina.jar to load those valves. The valve can't start up due to the explanation above (Tomcat's valves aren't designed to be used outside of a normally-running Tomcat). Yes, your webapp counts as "outside" of a normally-running Tomcat because of where you've put the catalina.jar file.

You do have a couple of options:

1. Implement your own Realm, possibly borrowing code from Tomcat's JNDIRealm
2. Move catalina.jar from CATALINA_HOME/server/lib to CATALINA_HOME/shared/lib and remove it from your webapp's WEB-INF/lib directory

I'm not sure that implementing your own Realm makes any sense (see below) if we can get sf and Tomcat to play well together.

I haven't actually tried #2, but it might be as simple as that.

Note that SecurityFilter has no way to allow the setting of attributes on the authenticators, which are chosen based upon your choice of BASIC, FORM, etc.

FormAuthenticator.setSecurePagesWithPragma is not static, so you can't set it yourself anywhere, really. Since you've moved outside of Tomcat's authentication, you have the opportunity to put a Filter in front of SecurityFilter that sets whatever headers you need (or don't need) in order to get MSIE to operate properly. You may want to consult the Tomcat source code to see what the difference in behavior is between the different states of this flag.

If you feel strongly about implementing your own Realm, I can probably provide you with an example to go with: we wrote our own Realm for our project because we wanted to log failed login attempts, so I have an independent DataSourceRealm that you can use if you'd like. Note that JDBCRealm is not a very well-written Realm implementation in the first place, due to it's single-Connection strategy.

Good Luck,
-chris