geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Geronimo Security plans (from ApacheCon)
Date Tue, 10 Jul 2007 05:52:01 GMT
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:


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.

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