On Jul 11, 2007, at 11:28 AM, Joe Bohn wrote:
- it doesn't allow portlet webapps to define their own customized
security constraints, or to choose not to implement security at all.
Is this second point really desirable? What would be the practical
result of allowing a portlet to define it's own security or none at
all when included with the geronimo web console? I think that most
users would expect single-signon for the Geronimo web console. IMO
it would be really annoying to be prompted for additional
credentials when accessing a particular portlet once I've already
authenticated. If we are successful and have a lot of plugins with
console extensions then it might also become a problem to have many
different credentials to manage.
Good point. I agree that if the user only intends to extend the
admin console then they probably don't want to (or maybe even
shouldn't be allowed to) customize the security constraints for their
portlets. This second point was actually meant to underscore the
usage of pluto as a general purpose portal container in geronimo vs.
a portal container that is focused solely on administration
functions. When you broaden the scope to providing a general purpose
portal container I think the need for customizable security
constraints arises.
To address the first problem we might be able to do something like :
https://issues.apache.org/jira/browse/GERONIMO-973
where portlet webapps map the driver's security contraints into
their web.xml. But that's not very flexible since it requires the
portlet webapps to keep their security settings in synch with the
driver. And if they contain servlets like DWR then those have to
be dispatched through the driver as well. I'm also wondering if
that approach actually works across separately deployed modules
(it worked for webapps deployed inside the same EAR). But even if
we can work through all that I'm still hoping that our solution
can also address the second problem, since that would make the
portal available for general purpose use and not just as an
extensible admin console.
I like the idea of a general use portal. Perhaps we could have it
both ways?
1) To integrate with the Geronimo web console you must have your
portlets conform to some security and other standards. Part of
that would involve some standard Geronimo web console practices so
that this can be integrated under a single geronimo admin
authorization. Other parts might be necessary to link/protect the
portlet context, insert content in the appropriate place for
navigation, specify a navigation icon, utilize the Geronimo skin/
style sheets, etc....
agreed that establishing some new standards might be necessary. for
security I hope that we can leverage the existing portlet and jee
standards in such a way that :
- adding admin portlets that want to piggyback on the admin console's
existing security configuration is easy and straightforward.
something like : "add this small chunk to your web.xml" would be ideal.
- we don't get in the way or over complicate the use of the portal
for general purpose (non-admin) portlets, recognizing here that
general purpose portlet may require custom security or none at all.
2) If this portlet application does not include the necessary
"glue" to be included in the console then it could be deployed and
accessed as any other portlet might be deployed/accessed.
That might not make sense or be practical to implement but if it is
possible it would provide some flexibility for the user and
consistency for the geronimo web console. thoughts?
yes I think that's the idea. The key is to implement security such
that the pluto driver delegates as much of the security handling to
the portlet webapps as possible. That may be difficult since the
driver is ultimately responsible for servicing the HTTP request, and
it operates at the level where security constraints are typically
enforced. If we would need to write a bunch of extra code or,
worse, expect the app to then I would back off the general use portal
idea for now and just focus on using pluto for an extensible admin
console.
Best wishes,
Paul
