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
