Yesterday I succeeded in enabling JAAS Authentication on Tomcat 4: http://issues.apache.org/jira/browse/JS2-52
The problem is, it isn't working on Tomcat 5 because of a change in classloading introduced with Tomcat 5 for the JAASRealm.
The JAASRealm implementation on Tomcat 5 is different from the one on Tomcat 4 in that it sets the current Thread ClassLoaderContext to that of the Catalina core itself before accessing a LoginModule.
The developer adding this *feature* himself seemingly thought it might result in problems because it contains as inline comment:
"What if the LoginModule is in the container class loader ?".
I don't know if this is according to the JAAS specs or not but it is a nasty problem with the current Jetspeed architecture.
I've looked into the Tomcat 5 Bug Database and found issue 26475: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475
This issue exactly describes our problem.
But, Remy Maucherat, one of the lead developers, simply didn't find the issue a problem (2004-01-27 23:31):
"Obviously, the realm is a server component. As a result, all its dependent classes must reside in the server classloader. I do not see anything wrong with this."
And (2004-01-28 09:07):
"/WEB-INF is the application classloader, not the server classloader. This does not convince me at all. If somehow the realm can look up stuff, the conext CL is the webapp CL during the realm initialization. If nobody looks at this report within a week, I'll close it again."
And finally (2004-02-02 20:08):
"As there has been no activity, and I think the classloading behavior is the right one, I am closing this bug. Please use tomcat-user if you are still experiencing problems."
So it seems we're toast.
To be able to use JAAS Authentication on Tomcat 5 we are required to put the RdbmsLoginModule in the server classpath. This can't be done right now: it requires most of the persistence, rdbms and security classes and putting them all there won't do either (leads to other classloader issues and if it were working it would lead to two different OJB caches in which changes made through the portal won't be seen by the LoginModule or no cache should be used for the login).
As far as I can see there are three possible solutions:
1) Remodel Jetspeed in such a way that the RdbmsLoginModule can be used from the Tomcat 5 server classpath. I guess this will take a lot of work but I'm not the designer of the security component so maybe others see a short way out?
2) Try to convince the Tomcat crew to revert to the old Tomcat 4 behavior. Maybe conditionally with an additional realm parameter?
I have a gut feeling they are not open to this but maybe Jetspeed is important enough to make a difference???
3) Create an extended JAASRealm implementation or patch the current one without the new Tomcat 5 ContextClassLoader problems. This would be a short and simple solution (I tried it out: 5 minutes work) but it creates a dependency on the current Tomcat 5 implementation and requires putting the hacked/extended class in the server classpath.
Please comment.
Regards,
Ate
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
