Hi, This is an old issue, but have a small twist in the requirements that I need to satisfy and that can't be done using the solution outlined in the following article. I am just wondering if things have changed in tha past one year. Also, I apologize for the cross-post, but I thought it was relevant. Here is my scenario. I want to expose my Struts based site to our recently added business partners, either a web service or like a "portlet". And of course, I need to authenticate them and authorize the resource against their role. I want to be able to take the "j_username","j_password" and accomplish everything in one call other than asking them to authenticate as a "side-effect" of requesting a resource? My quick and dirty solution was to make an internal http request and deal with authentication and send the "extracted" response back.
<OT> I had tough time making my manager understand why it took a little longer than it should have been, who gave "30 mts" as estimate to our customer to accomplish this. I ended up taking an hour, including testing :-). </OT> Thank you, Vishu -----Original Message----- From: Robert Hall [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2003 10:19 AM To: Tomcat Users List Subject: Re: Application-level security Chris, The August 2003 Java Developer's Journal (vol 8 issue 8) has an article you might want to take a look at: "ActiveAuthentication - Extending J2EE form-based authentication" by Thomas Beck; <http://www.sys-con.com/java/article.cfm?id=2160>. Yes, logout is implemented by invalidating the session. Since you provide the login module code you can do whatever is required/desired after the user is authenticated before returning control to the app server (Tomcat). If you aren't familiar with JAAS (Java Authentication and Authorization Service) you should take a look at <http://java.sun.com/products/jaas/> and <http://java.sun.com/security/jaas/doc/api.html> before deciding to roll your own authentication/authorization layer. Regards, Robert Christopher Schultz wrote: > All, > I've been involved in quite a few web-based applications, and every > time I've done one, the team has a different kind of application-level > security. > > I'm interested in people's thoughts on the following methods. > > 1. Using container-based authentication and authorization (in the form > of j_security_check and the <security-constraint> sections of web.xml). > > Here are the advantages I see for this: > > - Declarative security restrictions. I think this is great! No matter > what I decide to do, the fact that I can change the security > restrictions using a file instead of code will be mandatory. > > - Container supports the actual login procedure, so I don't have to > write/manage the code. > > Unfortunately, there are also some disadvantages, and some of them are > deal-breakers: > > - No logout function (does session.invalidate() kill it? it occurs to > me that it doesn't, but I haven't yet tried) > > - If you hit a resource that requires auth, you go to the login page, > login, and then go to the page you were trying to hit. I need to be > able to first send the request to an action that will set up the > user's session before the "destination" resource is accessed. > (deal-breaker) > > - If I want to modify usernames or passwords as they are read by > j_security_check, I cannot do this. A concrete example: often, it is > preferable to have case-insensitive usernames and passwords. Using > j_security_check, I cannot flatten-out the case before the > authorization is done. (I suppose this might be solved using a custom > Realm). (deal-breaker) > > Given that container authorization has a few shortcomings, there are > also two other obvious styles of AAA: > > 2. Do it myself using action-level code. Each action (in my case, > struts, but it really doesn't matter) must perform its own check. > > This burdon can be lessened by inserting a common superclass that can > handle the checks, redirections to login, etc., but that would require > me to re-code most of my existing actions because they either need to > call an authorization method provided by the superclass or the > superclass must implement a "final" version of the request handler > method and then call an abstract method defined in the subclass. This > seems cleaner yet requires more code changes. > > On the upside, I have complete control over the login flow, and I get > to keep the desired declarative security model. (Does anyone know if > there's an easy way to grab the <security-constraint> stuff from the > web.xml file, or would I have to parse it myself and keep my own data > structure for this purpose?) > > On the downside, I now have to write this code and maintain it. Also, > the <security-constraint> and j_security_check conspire together to do > really sexy things like cache POST data and send it ultimately to the > desired resource. It would take me some time to clone that functionality. > > 3. Do it myself using a Filter. This has the same advantages and > disadvantages as #2 up there, except that I wouldn't have to change > any of my actions to support the security checks. I think I'd prefer > this techniqu, but I have no experience writing filters. They should > be pretty darned easy, right? > > So, if anyone has some great words of wisdon, I'd love to hear them. > > I'd also love to hear about any frameworks that I could add to my > applications that would handle this stuff for me. Again, I'd rather > re-use something than code it and maintain it myself. > > I'm not trying to start a flame war about AAA, so feel free to email > me directly if you don't want to clutter the list. > > Thanks, > -chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "MMS <firstam.com>" made the following annotations on 09/20/2004 12:11:51 PM ------------------------------------------------------------------------------ "THIS E-MAIL MESSAGE AND ANY FILES TRANSMITTED HEREWITH, ARE INTENDED SOLELY FOR THE USE OF THE INDIVIDUAL(S) ADDRESSED AND MAY CONTAIN CONFIDENTIAL, PROPRIETARY OR PRIVILEGED INFORMATION. IF YOU ARE NOT THE ADDRESSEE INDICATED IN THIS MESSAGE (OR RESPONSIBLE FOR DELIVERY OF THIS MESSAGE TO SUCH PERSON) YOU MAY NOT REVIEW, USE, DISCLOSE OR DISTRIBUTE THIS MESSAGE OR ANY FILES TRANSMITTED HEREWITH. IF YOU RECEIVE THIS MESSAGE IN ERROR, PLEASE CONTACT THE SENDER BY REPLY E-MAIL AND DELETE THIS MESSAGE AND ALL COPIES OF IT FROM YOUR SYSTEM." ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
