On Mon, 9 Aug 2004 10:35:14 -0400, Tom McCobb <[EMAIL PROTECTED]> wrote: > I have a struts app that I am deploying in WebSphere 5.1. Everything works > fine, no issues with WAS per se. Now I am trying to activate security and I > am running into some bumps in the road. > > The security setup is simple: With global security enabled on WAS, > authenticating against ldap (openldap repository in the test environment), I > only need to designate in my web.xml a security-constraint indicating which > resources are protected, and a login-config which indicates the name of the > login page to use. The login page must call a WAS servlet called > j_security_check. When an unauthenticated user tries to navigate to a > protected resource, WAS will redirect the user to the login page designated > in the login-config tag, and process the login from there. If anyone is > reading this, you probably know all this already. >
Yep :-). > From the looks of things, using the above scheme, I do not need to define a > path in struts-config.xml to the login page, as I would normally do. That is correct. > With index.jsp as my welcome page, which contains only a redirection to the entry > point path in my struts-config.xml, I expect WAS to kick in and redirect any > user trying to access "sessionStart.do" first to the designated login page > before allowing access to the struts action. My security-contraint in fact > protects "*.do". This is how IBM sets up its admin console for WAS, in > fact, although they incorporate everything into a form bean/action class, > and I instead detour out of struts just for the login process. I am not > having much diffculty with authentication in this manner, although > authorization is another matter. One thing to double check is that your welcome page really does do a *redirect* to sessionStart.do, rather than a <jsp:forward>. The latter will not kick in the container managed security, because they are only applied on the URL that is originally requested from the client (which will be the one for the welcome page in this scenario). Using "*.do" is the correct URL pattern for all the rest of the requests, since that is the URL that the form submit actually uses. However, it won't help you deal with fine-grained authorization (i.e. different people can execute different actions). For that, you can either define separate mappings in your security constraints (with different user roles required for access), or use the "role" attribute on the <action> element to ask Struts to check for the presence of that role. > > So my question is, what is the best way to do this? Should I protected the > static index.jsp instead of any call to the action servlet, or both, or all > resources (I have read through and tried to implement the IBM example of > using SSL for unathenticated access to the login.jsp, and non-secure > authenticated access to everything else)? Should I make a greater effort to > incorporate the entire procedure into a struts form.action class as IBM has > done (and if so, is there any particular trick to calling j_security_check > from my action class?). > > Any suggestions will be appreciated. > > T. McCobb > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
