[ 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
