geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: Geronimo Security plans (from ApacheCon)
Date Wed, 11 Jul 2007 17:00:36 GMT

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

Best wishes,

View raw message