Mohan: I just finished setting up container-managed FORM-based authentication and getting it working, based on advice from several people on this mailing list. I'll pass on what I learned, and others can add to it or correct my advice. I'm assuming that you know how to set up container-managed FORM-based authentication, and that your question only applies to its relationship to Struts. If that is not the case, you can review the replies I received to my original posting, or write back and I will provide detail.
Container-managed FORM-based authentication is separate and apart from the Struts framework, and indeed can be applied to an application that is not based on Struts. When you set up FORM-based authentication, you specify a login page and login error page. When the user enters a URL that falls within the <security-constraint> and <web-resource-collection> you specified in your web.xml, the container takes over and pops up the login page you specified in your <login-config> entry. Assuming that your login page form specifies "j_security_check" as the action, when the user hits the submit button, control passes back to the container, which validates j_username and j_password against the container's security realm; if they are valid, then the container passes control to the <welcome-page> specified in your web.xml. If they are invalid, the container passes control the error page you specified. Since this validation is performed by the container, you do NOT want a Struts ActionForm associated with the login page, nor do you want an Action associated with it. If you have prep work you need performed, you should perform it in the Action associated with your welcome page. It will get performed when the login passes the container's validation and the container passes control to your welcome page. It IS useful, however, to have a <global-forward> back to the login page, so that your login error page can direct the user back to the login page, to re-login after an error, and so that, after he logs out, your logout confirmation page can direct him back to the login page. Also, your login page and login error page may contain Struts tags. Since I'm still in the process of converting my app over to FORM-based authentication, I haven't completely worked out the interaction between the container and Struts as far as subsequent login-checking is concerned. I don't think you need to check the user's login status on your JSPs and in your actions, because I think the container will force the user to the login page if he tries to enter the app "in the middle" via a bookmark or something. I will be testing this in the near future. However, I do know that you can gain access to the username and/or role via the Jakarta Taglib request library; for example, I originally converted my app to container-managed BASIC authentication expressly so that I could use the <req:isUserInRole> tag to vary menu and screen content based on the user's role. I apologize for my incomplete knowledge, and as I said, I encourage others to correct or add to what I have written, but since no one else has yet replied to you, I figured you'd rather have some reply than none. I'll be smarter in a few days, after I've had a chance to fully integrate the container-managed FORM-based authentication facility and do all my testing. -- Charlie -----Original Message----- From: Mohan Radhakrishnan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 3:09 AM To: 'Struts Users Mailing List' Subject: RE: Logout in a container-managed security environment Hi, I am not sure how Container-managed login security will affect Struts loginform and loginaction. How do you forward to the main screen after login in this case? bye, Mohan -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:43 PM To: Struts Users Mailing List Subject: Re: Logout in a container-managed security environment It all falls under "Container-Managed Authentication". It's just a different authentication method. FORM-based authentication is what you see ... on a lot of sites :-) (either that or custom [roll-your-own] authentication) where you get the login prompt in the form of an actual page. The keys are: - submit to action="j_security_check" - field named "j_username" - field named "j_password" You would configure your security-constraints the same way you do now. This is a servlet specification thing. The only thing that you (should) have to change is the type of authentication (there is additional configuration for form-based auth - must specify login page and error page). Apart from the minor differences in configuration, it really is as straight-forward as the above. Note that you'll have to configure a realm for the container to lookup the users in. This could be a flat-file, a DBMS, or JNDI resource. Of course, you could probably "roll your own" here too (Tomcat lets you anyway), so you're not really constrained to using only those provided. For more information on realms, see your servlet container's user guide - that is container specific (the configuration is anyway). Oh, nevermind - you had to do that for BASIC as well - duh. Ok :-) That's really it. Here is my form-based auth config - it should look strikingly similar to what you already have ;-) <login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>/member/login/cmaLogin.jsp</form-login-page> <form-error-page>/member/login/error.jsp</form-error-page> </form-login-config> </login-config> I reference Jason Hunter's book Java Servlet Programming, and also Hans Bergsten's book Java Server Pages (both from O'Reilly). Both of them include information on this topic. I think I tend to refer to Hans' book more often though ... though I'm not sure why :-) I think it's because that's the one I have it bookmarked in. You should also be able to reference the servlet specification itself. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> Charles McClain Phone: 603.659.2046 email: [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
