Eddie: Thanks for adding on to my reply. As regards your statement in reference to role-based menu and screen variation, "Yes, this is one of the biggest benefits (that I see) of CMA over 'roll-your-own' approaches", let me add another consideration:
I've worked on a number of commercial webapps that had "roll-your-own" authentication embedded throughout the application. Invariably, business clients who purchase these webapps want to wrap them in their own portal or otherwise "re-brand" them.. As I'm sure you know, portal or "wrapper-application" users will almost always have already been authenticated, and it simply isn't an option for the webapp being "wrapped" to require a 2nd login. Depending on the specifics of the "roll-your-own" authentication scheme and how it's embedded, it can be VERY difficult to pass the portal's or "wrapper's" user object -- and possibly role object -- through to the "wrapped" application and not force the user to re-login. Since you as a software vendor can never know to whom you're going to be selling your app, you can't know in advance what portal or "wrapper-application" authentication schemes you're going to have to adapt to. If you use CMA, however: -- You can transparently adapt to whatever percentage of portals or "wrappers" also use CMA; -- You can cite industry literature recommending CMA as the "preferred" authentication method, making your position much more defensible; -- Even if, worst case, you have to adapt to the portal's or "wrapper-application's" authentication scheme, the fact that there are standards for CMA make it likely that you will have to do less work than if you invent your own authentication and role scheme. -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 2:11 PM To: Struts Users Mailing List Subject: Re: Logout in a container-managed security environment Charles McClain wrote: >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. > You could get creative in your approach to this. If my other post ever hits the list you'll see an outline for how you can do so. I *believe* I, at one point, had my login/error pages specified as actions, actually. I ... can't recall why I went back to JSPs. I think I was having some stupid errors that had to do with my "tripping" through my config (accidental key-in errors) - I believe you should be able to use actions to refer to your login/error pages. Try it :-) If it doesn't work, scratch it. >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. > You really should have no direct reference to the CMA-oriented login page whatsoever. You do not have the ability to invoke it directly. >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. > Yes, this is one of the biggest benefits (that I see) of CMA over "roll-your-own" approaches. There are, however, "roll-your-own" approaches which can provide this same functionality. You could take a look at securityfilter.sourceforge.net for one possible alternative. It requires a container to be servlet spec 2.3 compliant (filters are a 2.3 thing), but allows you to actually include your realm in your application - and would be a container-independent realm solution. Most containers will let you "roll-your-own" realm (I believe - I know for certain Tomcat does, and understand that others will, as well). Whichever way you go, it's still "make-based" login (authentication is done by the container, in response to the user requesting a restricted resource). To get "let-based" logins, you have to either do something creative, as I've suggested, or resort to implementing your own security (authentication) service. Of course, if you implement your own ... I'm not aware of how you could override isUserInRole() etc. I think there are approaches to this using Filters though. >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 > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
