Hi Erik, Not too long ago I struggled with this issue too and also played with the SecurityFilter (on sourceforge.net) but it didn't work with JBoss. And so after digging and digging I came up with my own security filter that Does work with JBoss and in fact can be adapted to more Application server.
Though it is not as fancy in terms of configuration, it is sure working for me and since then I have no headaches - at least not from that direction :) If you are interested in the code, send me an email. Regards, Erez -----Original Message----- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 6:43 PM To: Struts Users Mailing List Subject: Re: [OT] JBoss, Jaas and Struts The helpfulness of people on this list continues to amaze me. Glad to know I'm not the only one struggling with this! I will play with the technique described when I get a chance, and I will let everyone know how it goes. But that may be next weekend. Meanwhile, I will post this general solicitation for advice to the list: I have a couple different Servlet-based apps that will be deployed on JBoss and/or Tomcat. Both will be exposed to the Internet, and both will require SSL -- at least server authentication and encryption of credentials (for sure), if not encryption of all content (maybe) and even SSL client authentication (probably not). On one, I will get full access to the Server box (we are planning to use JBoss 3.2.4). But, unfortunately, they are going to have Windows running on the box (ack). Had it been a unix box, my plan would have been to put an Apache in front of the JBoss server and to try to configure all the SSL stuff via Apache, because I know that is commonly done and I know it would be easy to get help doing it. But, if that doesn't work out, is IIS-Tomcat or IIS-JBoss/Tomcat a viable option, securitywise? Or how about JBoss/Tomcat alone? For the other, we will probably use a hosting company such as webappcabaret. They run Tomcat and promise full SSL support. The main question I have is, are there best practices I can follow within the scope of my Struts/Servlet-related programming that will make it easier to "upgrade" the security of these apps, or does it really matter that much exactly how access to resources is controlled (within this scope I mean)? Typically I find myself in the same environment -- authentication/authorization data is stored via RDBMS, an app-specific login is programmed for authentication, and the Servlet-related processors check "User.Permissions" objects stored as HttpSession attributes for authorization. Thanks again, Erik Rick Reumann wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
