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 15:37:14 GMT
I've committed this in rev 554977.  Please speak up if you have  
comments or objections or encounter problems.

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