[jira] Updated: (GERONIMO-430) Generalize security realms, consolidate logic into Login Modules

["Aaron Mulder (JIRA)" <de...@geronimo.apache.org>]

     [ http://nagoya.apache.org/jira/browse/GERONIMO-430?page=history ]

Aaron Mulder updated GERONIMO-430:
----------------------------------

    Assign To: Aaron Mulder

> 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

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