portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Ford" <caius1...@hotmail.com>
Subject Re: [J1] [PROPOSAL] Secure Actions enhancement
Date Sat, 10 Jan 2004 03:59:09 GMT
>From: David Sean Taylor <david@bluesunrise.com>
>Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
>To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
>Subject: Re: [J1] [PROPOSAL]  Secure Actions enhancement
>Date: Fri, 9 Jan 2004 16:37:02 -0800
>
>
>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

That's fine with me.

>
>>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'


Originally, the check was there to avoid hard coding a specific role in the 
action.  Also, this provides a method of security for Turbine actions as 
well as portlet actions.

I like the idea of using the portlet's security access.  The only question I 
have deals with action events.  Most of the portlets were written before the 
GenericMVCPortlet and GenericMVCAction were created.  To fire 
actions/events, they specify the action on the url.  Because of this, 
Turbine runs the action event before the GenericMVCAction does.  When this 
happens, there is no portlet in the context.  What should be done in this 
case?  Can the security access still be used?

_________________________________________________________________
Scope out the new MSN Plus Internet Software  optimizes dial-up to the max! 
   http://join.msn.com/?pgmarket=en-us&page=byoa/plus&ST=1


---------------------------------------------------------------------
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