Erik Weber wrote:
Dang I thought I was onto something! I guess I'll stick to my "User" object in each session, and just try to make sure I centralize the auth checks as much as I can. Dunno why I ever wanted to change it, anyway.
Thanks Craig for your time.
I also sent your question on to a co-worker and he had this to say...
Craig if you have any comments regarding below I'd be interested in forwarding on to my co-worker here as well. Thanks.
======================================
This very topic has given me plenty of headaches. Only by diving into the Tomcat code did I start to figure out what was going on.
The issue is that the login must happen in two places since both JBoss and Tomcat security were designed to work standalone. JBoss accomplished the integration of the two by hacking Tomcat to use JBossSX as a security realm while allowing Tomcat to continue collecting its own login credentials.
When you performed your JAAS login within your action, you only authenticated yourself with JBoss. Since doing so bypassed the aformentioned hack, Tomcat never authenticated and the user principal was never applied to the session.
I had a very similar issue not too long ago and when I finally figured out how JBoss/Tomcat integrated, my brain started spinning trying to figure out how to do a more intelligent form login through the JBoss/Tomcat stack. Fortunately form authentication wasn't a requirement for the immediate problem so I didn't put too many cycles on that problem.
The moral of the story is that you can't bypass j_security_check without cutting Tomcat out of the authentication loop. You can't proxy j_security_check either. I tried some VERY creative hacks that way and none of them worked. Tomcat was designed specifically to not allow it. Too many potential exploits there.
There is a possible solution if you're willing to apply a little elbow grease and bend the JAAS spec a little. Download the Tomcat source and take a look at org.apache.catalina.authenticator.BasicAuthenticator. That's a good reference for how Tomcat authentication works.
Now take a look at the FormAuthenticator in the same package. This one is a bit more complex in that it saves the initial request so that it can replay it once authentication is complete.
It is conceivable that you can write a StrutsFormAuthenticator that forwards to the ActionServlet to collect the credentials. Once you have your new authenticator, you can register it by adding it to org/apache/catalina/startup/Authenticators.properties with a key like "STRUTS". Now go back to your web.xml and replace "FORM" with "STRUTS" and next time Tomcat deploys your war it should load up with your custom authenticator.
Be aware that JBossWeb has its own shadows of Tomcat authenticators (the aformentioned hacks). Instead of extending Tomcat classes directly, you must extend these and you must patch the org/jboss/web/tomcat/tc4/Authenticators.properties file in deploy/jbossweb-tomcat41.sar/tomcat41-service.jar with your "STRUTS" reference.
Good luck! ============================================
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
