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]



Reply via email to