Re: [OT] JBoss, Jaas and Struts
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. Erik Craig McClanahan wrote: On Sun, 18 Jul 2004 21:50:19 -0400, Erik Weber [EMAIL PROTECTED] wrote: So, I am trying to use the JAAS implementations that JBoss provides, which are configurable via login-config.xml. Now, if you configure that file appropriately and create a login page that follows the J2EE specs for container-managed login (the form action is j_security_check, the username field is called j_username and the password field is called j_password), the container does indeed propagate the authenticated subject to the web-app environment somehow; you can use the methods such as request.isUserInRole successfully. However, with the form action having to be set to j_security_check, you lose the link to the Struts controller, and thus give up Struts stuff like form validation, error redirecting, etc. That is as it should be. When you create a form login page (for container managed security), what you are essentially doing is designing a page that is part of the *container*, not part of your *application* -- in other words, the only thing you get to do is make the login page visually look like the rest of your app. It is not, in any way shape or form, actually part of your app. Therefore, you can't assume things like Struts validators. To grasp this more fully, switch your app to use BASIC authentication instead of FORM, so that the browser pops up its login box. See how you don't have any way to specify validators on the input dialog, or control where the input goes? That's because form based login is an exact analog to that procedure. So I toyed with the idea of bridging my Struts login page (action != j_security_check) with the container, by somehow processing the form submittal on my own, but then forwarding the username and password as j_username and j_passsword to this j_security_check resource, but I couldn't figure out how to do it. I even went so far as opening an HttpURLConnection to http://localhost:8080/j_security_check; and setting the username and password as request parameters, just to see if it would work. Yeah, it's been a long day. Anyone have an idea on this approach? Yah, I do ... give up on expecting any portable solution that will work across servers. The current specs do not provide for that, although there are current JSRs under way to address that precise concern. So I went the route of the typical examples; I wrote a login Action that instantiates a LoginContext using the domain I have configured in login-config.xml, provided my own CallbackHandler to submit the username and password, etc. And the login method does work -- it does authenticate using the database I specified in login-config.xml, but yet somehow the Subject is not propagated to the web-app environment the way it is when you login using the form action j_security_check, and so I still cannot use the methods such as request.isUserInRole. So obviously whatever intercepts the call to j_security_check is not only doing authentication, but it is taking some extra step to let the container know that the user has been authenticated. I know this is true because the request.isUserInRole method works when I do it that way. I iterated all the session attributes and there are no new ones present after authenticating with j_security_check. Does anyone know what this missing step is, and how I can do it from my own code? Or am I wasting my time? If you want to use Struts features in your login page, you'll need to abandon container managed security. Perhaps something like SecurityFilter (a sourceforge project) might be useful to you -- but, if you're using EJBs and need the propogation of user identity from the web tier to the EJB tier, this is not likely to work. The only possible solution would be something your app server itself provides. Thanks if you even took time to read this! Erik Craig - 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]
Re: [OT] JBoss, Jaas and Struts
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]
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
RE: [OT] JBoss, Jaas and Struts
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
[OT] JBoss, Jaas and Struts
Kindly let me know if this is too off-topic. I ask here for reasons I think probably go without mention: Smart and helpful people participate on this list, and I'm sure many are producing Struts apps that run on JBoss. I am using JBoss 3.2.4. I am trying to integrate my app with JAAS. I have followed what JAAS literature I could find on the web, including the JAAS howto that is available from Scott Stark of the JBoss group. This is a complex document and so if the answer is there, please forgive me as I have already read it two or three times and am finding this subject matter difficult. All the examples I have seen on the web (such as at JavaWorld) show you how to implement your own JAAS classes (I don't need to do this because I can reuse one that JBoss provides). The thing I cannot understand is why they go through all the trouble of implementing LoginContext, LoginModules, etc., only to, in the end, store the Subject instance in the session and repeatedly check that for every request before allowing commands to be executed. In other words, they go through all this trouble to follow the JAAS API and yet you still cannot use the methods like HttpServletRequest.isUserInRole that are built into the Servlet API. I don't see how this is really any better than rolling your own; it's still Java code, it's still portable, and it's still querying whatever resource (DB) by which you store your user data. Storing the Subject instance in the user's session and checking it for every request -- how is that any different from checking your own User object? So, I am trying to use the JAAS implementations that JBoss provides, which are configurable via login-config.xml. Now, if you configure that file appropriately and create a login page that follows the J2EE specs for container-managed login (the form action is j_security_check, the username field is called j_username and the password field is called j_password), the container does indeed propagate the authenticated subject to the web-app environment somehow; you can use the methods such as request.isUserInRole successfully. However, with the form action having to be set to j_security_check, you lose the link to the Struts controller, and thus give up Struts stuff like form validation, error redirecting, etc. So I toyed with the idea of bridging my Struts login page (action != j_security_check) with the container, by somehow processing the form submittal on my own, but then forwarding the username and password as j_username and j_passsword to this j_security_check resource, but I couldn't figure out how to do it. I even went so far as opening an HttpURLConnection to http://localhost:8080/j_security_check; and setting the username and password as request parameters, just to see if it would work. Yeah, it's been a long day. Anyone have an idea on this approach? So I went the route of the typical examples; I wrote a login Action that instantiates a LoginContext using the domain I have configured in login-config.xml, provided my own CallbackHandler to submit the username and password, etc. And the login method does work -- it does authenticate using the database I specified in login-config.xml, but yet somehow the Subject is not propagated to the web-app environment the way it is when you login using the form action j_security_check, and so I still cannot use the methods such as request.isUserInRole. So obviously whatever intercepts the call to j_security_check is not only doing authentication, but it is taking some extra step to let the container know that the user has been authenticated. I know this is true because the request.isUserInRole method works when I do it that way. I iterated all the session attributes and there are no new ones present after authenticating with j_security_check. Does anyone know what this missing step is, and how I can do it from my own code? Or am I wasting my time? Thanks if you even took time to read this! Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] JBoss, Jaas and Struts
On Sun, 18 Jul 2004 21:50:19 -0400, Erik Weber [EMAIL PROTECTED] wrote: So, I am trying to use the JAAS implementations that JBoss provides, which are configurable via login-config.xml. Now, if you configure that file appropriately and create a login page that follows the J2EE specs for container-managed login (the form action is j_security_check, the username field is called j_username and the password field is called j_password), the container does indeed propagate the authenticated subject to the web-app environment somehow; you can use the methods such as request.isUserInRole successfully. However, with the form action having to be set to j_security_check, you lose the link to the Struts controller, and thus give up Struts stuff like form validation, error redirecting, etc. That is as it should be. When you create a form login page (for container managed security), what you are essentially doing is designing a page that is part of the *container*, not part of your *application* -- in other words, the only thing you get to do is make the login page visually look like the rest of your app. It is not, in any way shape or form, actually part of your app. Therefore, you can't assume things like Struts validators. To grasp this more fully, switch your app to use BASIC authentication instead of FORM, so that the browser pops up its login box. See how you don't have any way to specify validators on the input dialog, or control where the input goes? That's because form based login is an exact analog to that procedure. So I toyed with the idea of bridging my Struts login page (action != j_security_check) with the container, by somehow processing the form submittal on my own, but then forwarding the username and password as j_username and j_passsword to this j_security_check resource, but I couldn't figure out how to do it. I even went so far as opening an HttpURLConnection to http://localhost:8080/j_security_check; and setting the username and password as request parameters, just to see if it would work. Yeah, it's been a long day. Anyone have an idea on this approach? Yah, I do ... give up on expecting any portable solution that will work across servers. The current specs do not provide for that, although there are current JSRs under way to address that precise concern. So I went the route of the typical examples; I wrote a login Action that instantiates a LoginContext using the domain I have configured in login-config.xml, provided my own CallbackHandler to submit the username and password, etc. And the login method does work -- it does authenticate using the database I specified in login-config.xml, but yet somehow the Subject is not propagated to the web-app environment the way it is when you login using the form action j_security_check, and so I still cannot use the methods such as request.isUserInRole. So obviously whatever intercepts the call to j_security_check is not only doing authentication, but it is taking some extra step to let the container know that the user has been authenticated. I know this is true because the request.isUserInRole method works when I do it that way. I iterated all the session attributes and there are no new ones present after authenticating with j_security_check. Does anyone know what this missing step is, and how I can do it from my own code? Or am I wasting my time? If you want to use Struts features in your login page, you'll need to abandon container managed security. Perhaps something like SecurityFilter (a sourceforge project) might be useful to you -- but, if you're using EJBs and need the propogation of user identity from the web tier to the EJB tier, this is not likely to work. The only possible solution would be something your app server itself provides. Thanks if you even took time to read this! Erik Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
