This may not be perfect, and I welcome any criticism to this approach: abstract class extends ActionSupport which overrides execute() to authenticate requests and then return a call to abstract method, say, doAction(), or error if they are not authenticated/timed out.
Each action which needs to be protected simply extends the above abstract class and implements doAction(), just as you would normally override execute(). Make execute() final in the abstract class... Add another abstract method to get a group authentication level (implemented by each action's class) and you have a fairly robust and straightforward authentication scheme, IMHO With proper negative testing, you can be certain any developer didn't forget to extend/implement the 'security' action for any given action that should be restricted -----Original Message----- From: CRANFORD, CHRIS [mailto:chris.cranf...@setech.com] Sent: Thursday, August 20, 2009 4:25 PM To: user@struts.apache.org Subject: Struts2 with Authentication & Security I am currently preparing the steps to port a legacy Struts1 application to Struts2. The rewrite of the web application also includes a transition from Tiles to Sitemesh along with the introduction of the Spring and Hibernate frameworks. The authentication and security model used in the Struts1 application was very simple and one of the pitfalls resulted in lack of overall flexibility and ease of managing user roles and permissions. One of the biggest goals of this rewrite process is to really spend a good chunk of time looking at alternatives that make the most sense for what we're trying to accomplish. The application is mainly a query-based tool for reporting a wide range of data to a very large end user community. There are also possibilities for gathering data from this user community and storing it depending on specific business case needs. Since the user community could span users that are customers, to in-house end users, site/local management, and upper executive management, the options and data presented to these users will need to vary. Is there any internal way within Struts2 that is recommended over another to embed logic to support per-action/page security? Is there an internal way to insure that the user is authenticated prior to servicing the request? I've read about Interceptors versus using something like JAAS. Are there benefits of one over another? I'd rather not introduce a new framework atop of Spring and Hibernate given we're moving from Struts1 to Struts2 and Tiles to Sitemesh. It is a learning curve and adding new frameworks continues to agitate the issue. Thanks for everyone's feedback. Chris --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
