How about Pow2ACL? http://pow2acl.sourceforge.net/
David, have you used pow2acl? I like the idea of a good shared ACL library, but I see some potential issues, at least with their Struts integration.
First, from the website, it appears that they haven't caught up with even Struts 1.1, as they have an ActionServlet implementation which overrides processActionPerform, which was moved into RequestProcessor almost two years ago.
Still, it does provide a general API which could probably be adapted to the purpose, and they mention a web UI for some administration purposes.
Still, I think it would be better to implement the access check in the request processor rather than requiring you to use up your single inheritance extending from an action which provides that functionality.
Joe
Regards, David
-----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, December 06, 2004 5:46 PM To: Dahnke, Eric (Company IT); Struts Users Mailing List Subject: Re: Flexible ACLs using Struts
Assuming you can define an interface (like "AccessControlManager") and instantiate an implementation of the instance at servlet init time (using ServletContextListener or PlugIn), it should be pretty straightforward.
In the RequestProcessor you'd use the reference to the servlet to retrieve your manager. Then you'd fish out of the request or session whatever you know about the current user and client, and some config information from the ActionMapping like the path. Then you hand all these things a method on your AccessControlManager which evaluates the rules and tells you whether you should let them continue or not.
Is your problem figuring out how to pass in the necessary config information for the action? How do you model it? If you don't want per-path rules, then use the "parameter" property to pass in an "action-group" code or something, or if you need more config properties, extend ActionMapping and use the struts-config to set arbitrary bean properties.
Or is your problem figuring out how to deal with access denied scenarios? I could see where Struts' configuration options make that kind of cumbersome, since the API of RequestProcessor kind of assumes you've dealt with the response inside processRoles. The struts-chain code under development would make it easier for you to do more than just requestDispatcher.forward(...) from inside processRoles...
Does any of this help?
Joe
At 5:06 PM -0500 12/6/04, Dahnke, Eric (Company IT) wrote:Hello, For a few Struts apps in a row now, we've used the roles attribute and an overriden processRoles() method in a custom request processor to handle access control within struts apps. A user's Roles are gotten from the database at login and stored in the User object in the session. The User object has a hasRole() method that compares the user's roles to those that arrive in the ActionMapping, and the processRoles() method returns an ActionForward of "NotAuthorized" if there is no match.
I'm working on a new application, that needs configurable ACLs. For example, one client may choose to allow users of a certain role perform action X, other clients may not. There are 20 or 30 of these types of flexible actions.
Has anyone come up with a pragmatic way to implement flexible ACLs using Struts? Essentially, I need one Role to many Actions functionality, as where the roles="" attribute of struts-config gives me the opposite? Thx! --------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED]>For additional commands, e-mail: [EMAIL PROTECTED]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- 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]
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
