Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Message-ID: <3C44B985.3050100@hisitech.com>
Date: Wed, 16 Jan 2002 00:21:41 +0100
From: Santiago Gala <sgala@hisitech.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: Security Changes
References: <3C432693.50701@hisitech.com> <3C43A91C.9060108@apache.org>
 <3C445122.7020500@hisitech.com> <3C446309.3000502@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Paul Spencer wrote:

(I snip most. I agree with most of it)

>
>
> Missing group = all user have access based on roles. 

As turbine roles are defined in a triple group-role-user, this should 
better be rephrased as "all users have access based on roles in global 
group". I'm not picky, this is important. This misunderstanding is the 
root of most problems we have experienced. A user has *no* role unless 
you pick up a group.

>
> Missing roles = all user have "default access" 

This could be the users have the permissions returned by 
 data.getACL().hasPermission("xxx"), but, again, this is implemented in 
turbine as return hasPermission(permission, 
TurbineSecurity.getGlobalGroup());, so it means "access according to 
permissions in the global group"
The precise meaning of a role constraint is "data.getACL().hasRole( role 
) && data.getACL().hasPermission( "xxx" ) returns true", where xxx is 
the action to be performed. It restricts the permission further, since I 
could have view permission, but not clerk role, for instance.

>
>
> We also need to define a standard set of permissions:
> view       - Allows portlet content to be viewed and
>              added to pane
> customize  - Allows portlet to be customized 

This can/should be required at the portletset level

>
> minimize   - allows portlet to be minimized
>
> maximize   - allows portlet to be maximized
> remove     - allows portlet to be removed from pane
>
> move       - allows portlet to be moved in pane 

This one looks very difficult to implement, since in a two column 
layout, moving one portlet shuffles the rest (effectively moving them). 
Ideas?

>
>
>
> One other area the is related, it the ability to have common 
> portlet(s) the are maintained in one place for a group of users.  As 
> an example corporate E-mail and corporate News should be on all pages 
> and in the left column.  (I am not ask this be addressed now, just be 
> aware of this desired functionality while designing the security changes)

This again could be implemented with relative ease at the portletset 
level, except that a multi-column layout is *not* a portletset. I mean 
something like the customiser not allowing to modify a given part of the 
PSML. If a Document is composed of a (role=admin)set which includes 
several (unrestricted)portletsets, the user could modify only the inner 
ones, but should respect the structure of the outer one. We will work 
security in the PSML structure/customiser later on, when we have the 
basics sorted out.


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