geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder (JIRA)" <...@geronimo.apache.org>
Subject [jira] Resolved: (GERONIMO-430) Generalize security realms, consolidate logic into Login Modules
Date Sat, 20 Nov 2004 07:50:24 GMT
     [ http://nagoya.apache.org/jira/browse/GERONIMO-430?page=history ]
     
Aaron Mulder resolved GERONIMO-430:
-----------------------------------

     Resolution: Fixed
    Fix Version: 1.0-M4

Now there's a single GenericSecurityRealm

> Generalize security realms, consolidate logic into Login Modules
> ----------------------------------------------------------------
>
>          Key: GERONIMO-430
>          URL: http://nagoya.apache.org/jira/browse/GERONIMO-430
>      Project: Apache Geronimo
>         Type: Improvement
>   Components: security
>     Versions: 1.0-M2
>     Reporter: Aaron Mulder
>     Assignee: Aaron Mulder
>      Fix For: 1.0-M4

>
> 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:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message