org.apache.catalina.realm.JAASRealm does not verify any of the class names that are set through setRoleClassNames() and setUserClassNames(). If an incorrect class name (e.g. a typo) is configured in context.xml, this is unnoticed by JAASRealm. The result is that during authentication, when the subject's principals are checked against the configured class names, the principals are not recognised, and therefore not added to the subject. The fact an incorrect configured class name is currently not detected and logged makes it very hard to find the source of the problem. It can be easily fixed by checking the class names in the two methods mentioned above. The class must exist, and it must implement java.security.Principal, which is currently not enforced/checked by the code.
Created attachment 18668 [details] Proposed fixed version of JAASRealm. This version of JAASRealm validates the class names for setUserClassNames and setRoleClassNames. It verifies if the class exists, and if it implements java.security.Principal. If not, it logs a message (severe), that allows users to detect the incorrect class name. It might even be better if it threw an exception. I've also restructured the code to parse the comma-delimited class name string, as it was rather inefficient. It uses a StringTokenizer now.
Created attachment 18669 [details] Improved version of the patch No longer using StringTokenizer, but String.split, as StringTokenizer is considered legacy. Thanks to Sameer Acharya.
This looks like a good idea to enhance. However, please submit your patch in diff format rather than the whole file, that would make its review and application much faster: http://www.apache.org/dev/contributors.html#patches provides more details.
Created attachment 19306 [details] Patch of JAASRealm.java (in diff format)
Tom, thanks for providing this patch in diff form. I've applied it to the Tomcat 5.5 and 6.0 trunks, I really like it. Sorry it took so long.
While this patch might have improved feedback when an incorrect classnames are provided, it actually fully *breaks* JAASRealm usage when correct classnames are provided but need to be accessed through a ContextClassLoader. We at Apache Jetspeed-2 use the useContextClassLoader=true setting for hooking up our own custom Principal classes as these are provided through the portal application itself, not from a common/shared classloader. Because the new parseClassNames only does a simple Class.forName() check this now fails to validate our classnames for Tomcat 5.5.24 and later and thereby breaking our JAAS based security :( I suggest this to be solved by either: - reverting the patch - keep the current patch but *ignore* a ClassNotFoundException except for logging that it happened - run this method in the appropriate ContextClassLoader for the web app if possible FYI: we have a Jetspeed JIRA issue opened on this bug with some additional information: https://issues.apache.org/jira/browse/JS2-828 Hopefully this issue can be resolved quickly as right now we cannot run Jetspeed on Tomcat >= 5.5.24 Regards, Ate
See http://issues.apache.org/bugzilla/show_bug.cgi?id=44084 for the Tomcat 6 version of this issue. This has been fixed in the Tomcat SVN trunk, and should be integrated into the next 5.5 and 6 releases.
This has been fixed as per the comments in 44084.