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]
