The issue that needs to be addressed is securing the portlet actions. While it is possible for each action to implement its own security checking, it would be nice for there to be classes that one can simple derive from that already does the checking for you. Looking at the various portlet actions provided by Jetspeed, there are 3 main classes that provide portlet action support; GenericMVCAction, JspPortletAction, and VelocityPortletAction.
I propose providing 3 new classes; SecureGenericMVCAction, SecureJspPortletAction, and SecureVelocityPortletAction. These 3 actions would extend GenericMVCAction, JspPortletAction, and VelocityPortletAction. The actions would override the perform(RunData) method with the following implementation.
if(JetspeedSecurity.canUseSecureAction(rundata)) {
super.perform(rundata);
}The canUseSecureAction function would defer to a new method in the JetspeedSecurityService implementation which would provide an algorithm that determines if the current user is an administrator. The currently proposed algorithm is to compare the list of roles that the user is associated with a list of allowed roles in the JetspeedSecurity.properties file. If there is a match, the user is allowed access to the action.
Proposed Classes: SecureGenericMVCAction SecureJspPortletAction SecureVelocityPortletAction
Proposed Extensions: New method to Jetspeed security canUseSecureAction
Proposed property file changes: services.JetspeedSecurity.secure_actions.allowed_roles
As always, comments are welcome as well as any suggestions or total rewrites. :)
Thanks,
Jeremy Ford [EMAIL PROTECTED]
_________________________________________________________________
Enjoy a special introductory offer for dial-up Internet access � limited time only! http://join.msn.com/?page=dept/dialup
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
