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 14:31:18 GMT
There is some experimental work in sandbox/portals for an admin  
console that supports dynamic extensions.  One thing that it  
currently lacks is security, and I am wondering if these recent  
security improvements that David has made might affect how that can  
be implemented.

This experimental admin console uses pluto 1.2 for a portal  
container.  Pluto provides a "driver" webapp that is responsible for  
creating the portal pages.  First you deploy the driver webapp and  
when you want to add new portlets to your portal you deploy them in  
separate webapps and register their context roots with the driver.   
Then HTTP requests for portal pages are received by the driver and it  
uses cross context dispatch to route the request to the appropriate  
portlets and assemble their HTML into a page.

It seems like the most straight forward way to implement security for  
this type of configuration would be to add the security constraints  
to the driver webapp since it is a "choke point" for all HTTP  
requests thru the portal.  But this approach has at least two problems:
-  it leaves the portlet webapps unprotected from direct HTTP access  
since they are deployed in separate webapps
-  it doesn't allow portlet webapps to define their own customized  
security constraints, or to choose not to implement security at all.

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.

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

Thoughts and feedback would be very helpful!!

Best wishes,

On Jul 10, 2007, at 11:37 AM, David Jencks wrote:

> I've committed this in rev 554977.  Please speak up if you have  
> comments or objections or encounter problems.
> thanks
> david jencks
> On Jul 10, 2007, at 1:52 AM, David Jencks wrote:
>> So its a year and a half later.... I've finally made a bit of  
>> progress on the first of these goals.
>> Recently I replaced the only use of remote login with login over  
>> the openejb protocol.  This means that the client/server-side  
>> distinction is no longer relevant, and the login module wrapping a  
>> set of login modules is not needed either.
>> I've refactored the authentication stuff so that:
>> - we still have a GeronimoLoginConfiguration
>> - we can still (optionally) wrap principals to determine exactly  
>> which login module and realm they came from
>> - all authentication happens in a single vm, no sneaky remoting stuff
>> - we use the LoginContext to create the login modules directly  
>> from the AppConfigurationEntry[]
>> - registering and unregistering the subject and inserting the  
>> identification principal is done by a login module automatically  
>> added by the GenericSecurityRealm, rather than the  
>> JaasSecuritySession
>> This eliminates most of the hard to understand code including:
>> JaasLoginCoordinator
>> JaasSecuritySession
>> JaasLoginService
>> I've also removed the subject carrying protocol and the remoting  
>> jmx code since it isn't used.
>> I'm somewhat sorry to see all this sophisticated code Alan wrote  
>> go since it is a quite interesting solution to the problem of how  
>> to share authentication between a client and server, but I think  
>> it has proven to be fatally complex and not really a good solution  
>> to the original problem.  As we discussed at this apachecon  
>> security assertions seem to provide a better framework for  
>> thinking about these questions.
>> I opened GERONIMO-3303 about this and expect to be comitting after  
>> just a bit more cleanup.
>> thanks
>> david jencks
>> On Dec 23, 2005, at 6:37 PM, David Jencks wrote:
>>> At ApacheCon several of us got together to discuss security in  
>>> Geronimo.  These are my recollections, please expand/contradict/ 
>>> modify what I forgot or got wrong.
>>> People:  Alan Cabrera, David Jencks, Kresten Krab Thorup, Hiram  
>>> Chirino, Simon Godik (Others ???)
>>> Problems with the current implementation:
>>> - Distinction between client-side and server-side login modules  
>>> is too hard to understand and too ad-hoc: security assertions are  
>>> a better, standard, and more comprehensible way of getting the  
>>> same functionality.
>>> - The LoginModule wrapping a set of login modules serves little  
>>> purpose.
>>> Things we like and want to generalize somehow:
>>> - We'd like to extend the variety of approaches represented in  
>>> the CORBA csiv2 model to other transports and contexts beyond CORBA
>>> How we might get there:
>>> Simon gave us some hints about SAML and XACML and IIUC pointed  
>>> out that most of the basic ideas we need are worked out in detail  
>>> in these specs and that we can implement these ideas without  
>>> necessarily relying on the xml-centered implementation called for  
>>> in the specs.  In particular SAML extensively discusses security  
>>> assertions which are a more powerful and systematic way of  
>>> dealing with both the client/server login module problems and the  
>>> information dealt with by csiv2.  My current and very limited  
>>> understanding is that SAML indicates what kind of security  
>>> assertions can be made and how to transfer them between systems.   
>>> XACML provides a framework in which (among many many other  
>>> things) these security assertions can have effects on  
>>> authentication and authorization decisions
>>> Since ApacheCon I've started looking into XACML and SAML a tiny  
>>> bit and although I am not thrilled by the pointy brackets I think  
>>> this is an avenue we should investigate thoroughly.  I think it  
>>> can definitely provide the flexibility we want in the security  
>>> model: I think the challenge will be making the configuration  
>>> comprehensible and the implementation fast.  From my very brief  
>>> study it looks like XACML will provide a framework in which  
>>> authorization rules that include the request info provided by  
>>> JACC can be evaluated.  I'm not sure what else it will bring us :-)
>>> Many thanks,
>>> david jencks

View raw message