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]
