geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <>
Subject [jira] Created: (GERONIMO-430) Generalize security realms, consolidate logic into Login Modules
Date Wed, 03 Nov 2004 14:27:32 GMT
Generalize security realms, consolidate logic into Login Modules

         Key: GERONIMO-430
     Project: Apache Geronimo
        Type: Improvement
  Components: security  
    Versions: 1.0-M2    
    Reporter: Aaron Mulder

I'd like to generalize the security realm implementation, and make it take a more arbitrary/configurable
list of login modules.  That would let you implement features like auditing and lockout as
login modules, and hopefully entirely encapsulate Kerberos, SQL, and File access as login
modules.  Then you pick login modules from here and there and pop them into a general security
realm, and off you go.  It makes it all much more modular, and lets us reuse the same features
across realm types without needing to separately update multiple security realm implementations
to handle them.

To implement this, I'd suggest creating an interface such as DeployerSupport, to hold the
methods getUserPrincipals and getGroupPrincipals (or their equivalents; see issue 410).  Then
the LoginModules could implement that, moving that logic from security realm to login module
(though the realm could still provide a thin wrapper for it).

For example, look at the SQL realm.  Both SQLSecurityRealm and SQLLoginModule have database
logic, and they don't share connections or reuse code or anything.  If we make SQLLoginModule
implement DeployerSupport, then all the DB/SQL logic could go in the SQLLoginModule.  The
SQLSecurityRealm would suddenly have no SQL-realm-specific code, and could be replaced by
a generic realm.

The same could be done with the PropertiesFile realm and Kerberos realm, so long as we provide
a way to pass required options to the individual LoginModules.

If we consolidate all 3 of our realms on one SecurityRealm implementation class, then it woudl
be easier to make that one class support multiple login modules (issue 424).  This would also
let us solve the issue of passing options to login modules once, since it would need to be
handled in order to configure multiple login modules as well.  We could also consolidate down
to one way to pass options to login modules (issue 422).

If our combined realm took a ServerInfo parameter, that could provide the hook required for
issue 426.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message