portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J1] [PROPOSAL] Secure Actions enhancement
Date Sat, 10 Jan 2004 00:37:02 GMT

On Thursday, January 8, 2004, at 08:44  PM, Jeremy Ford wrote:

> The following proposal was spawned by this log in bugzilla:  
> http://issues.apache.org/bugzilla/show_bug.cgi?id=24939
>
> 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);
> }
>
+1
Although my vote is to not add the Secure action classes, and just 
build in security into the default portlet actions
IMO all actions should always be secured

> 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
>
Wouldn't you simply check the security access for the given user on the 
target portlet and instance?
Or is the 'allowed roles' an extra check besides the normal Jetspeed 
security constraints.

I was also thinking we can could add another Permission type, 'Action'




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message