Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of paulmcmahan@gmail.com
 designates 66.249.82.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=oE+W1xACHO6ckl5XWL6EQw7gaH50Hkxq5TJBbnGJgL1yEPog6l8pRpDJpUuqp7NR710uJsOxYhYmA88Qw14PpokkkoQl9TKbcX/pkpp+7ny3iKn6SW1ZlrtvKL/e4cQhftQkw+yQXZE5KfzCMM5WODiAUZM34O9GABXgoknt1KM=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <5BCB007D-A603-4489-B896-584D194EE2CD@yahoo.com>
References: <2CFAA659-D269-41C4-AD34-DF936A62A790@yahoo.com>
 <FE83AAF6-4904-4F7B-99C5-7730F23FB8BF@yahoo.com>
 <AD5D7B39-0807-481E-8A55-D63035D6D3BD@yahoo.com>
 <26B30BA8-BABE-4E64-8C07-10E36524313D@gmail.com>
 <4694F730.2020000@earthlink.net>
 <5BCB007D-A603-4489-B896-584D194EE2CD@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <63AD4C03-E412-459D-873E-5FAEBC54B0B0@gmail.com>
Content-Transfer-Encoding: 7bit
From: Paul McMahan <paulmcmahan@gmail.com>
Subject: Re: Geronimo Security plans (from ApacheCon)
Date: Wed, 11 Jul 2007 13:35:47 -0400
To: dev@geronimo.apache.org


On Jul 11, 2007, at 12:35 PM, David Jencks wrote:

>>> So maybe there is some way to configure the security for this  
>>> portal so that the driver has no security constraints at all by  
>>> default, and instead the security constraints can be defined by  
>>> the portlet webapps in ad hoc fashion.   When the driver receives  
>>> an HTTP request there needs to be some way of collecting the  
>>> credentials necessary to access all the portlets in the page and  
>>> then do the cross context dispatches as usual.  The questions  
>>> that arise are:
>>> 1.) how can the driver figure out what credentials will be  
>>> necessary to successfully perform a cross context dispatch to a  
>>> given portlet webapp?
>>> 2.) how can the driver prompt the user for credentials, or (even  
>>> better) delegate that responsibility to the portlet webapp?   
>>> ideally the portlet webapps could configure their security in  
>>> geronimo-web.xml and web.xml in whatever manner they like (FORM,  
>>> BASIC, DIGEST, etc)
>>> 3.) can/should the driver perform the login or should it pass  
>>> along the necessary credentials in the dispatched request and let  
>>> the portlet webapp handle its own login?
>
> I think you may be confusing authentication and authorization to  
> some extent.  I think that for now requiring someone to log in  
> before they can use the admin console at all is appropriate.  Their  
> identity then determines what they can do.

yes,  admin console functions require login.  The admin portlets are  
bundled together in a WAR that will have the appropriate security  
constraints defined in its web.xml.  The question I meant to pose is  
really not whether the admin console requires login but whether or  
not its necessary to also "promote" its security constraints and the  
corresponding deployment verbiage up to the driver webapp, since it  
actually handles the portal page requests.  The side effect of doing  
that is that *all* portlet webapps serviced by the driver will be  
subject to those constraints, not just the admin console.   That  
makes it impractical to use the driver for general purpose portlet  
webapps.

> At some time we may want to consider some kind of "role change"  
> system but I really don't think this is the time.  However I'm  
> happy to discuss it but lets start a new thread.

I'm not proposing that we implement a new security feature or a role  
change system.  Looking at your commit I was just too dense to  
understand whether or not you had already implemented what would be  
needed.  From your reaction it seems that more work and investigation  
would be needed.

>  I think the best way to approach this is to use an actual  portal  
> (jetspeed) which has a sophisticated system of portal permissions  
> to go along with the web permissions from the servlet spec and  
> portlet permissions from the portlet spec.  I really don't want to  
> get involved in turning pluto into jetspeed.
>
> I demonstrated some time ago that it's fairly easy to support  
> jetspeed portal permissions through jacc.

I agree that pluto is not intended to be an enterprise class portal  
and that it doesn't make much sense to try to make it one when  
liferay and jetspeed are already available.  For the admin console  
we're using pluto because its more consumable and provides what we  
need.   My goal here has been to explore the possibility of also  
exposing the admin console's portal container for general purpose  
use, hoping that it could provide 80% of what's needed for simple  
portal apps.  But I'm starting to let go of that idea since it seems  
that basic JEE security doesn't quite provide what is needed.


Best wishes,
Paul