Overview of Latest Security Changes

[Aaron Mulder <am...@alumni.princeton.edu>]

I've added the concept of login domains to the security realms.  However,
there's still some work required to fully integrate them.  Namely, the
deployment plan schemas and module builders need to be updated to specify
role mapping using (login domain / principal class / principal name) and
to specify automapping on a per login domain basis (since the principals
generated by automapping need to include a login domain).  I believe the
following classes are affected, and I've put todos in them (search for
"todo" and "login domain" on the same line), but it would be nice if
someone else would handle these changes.
 - Security
 - JettyWebAppJACCContext
 - JettyXMLConfiguration
 - OpenEJBModuleBuilder
 - ContainerSecurityBuilder
On a related note, you can now specify a login domain name for every login
module GBean.  This is not required for login modules that don't represent
login domains (e.g. an auditing module), but it is required for every
login module that does represent a login domain.  Further, since our role
mapping is essentially broken temporarily (it takes a realm name instead
of a login domain name), the security stars only align if the login module
login domain name matches the realm name.  Once we switch realm mapping to
use login domain names instead of realm names, this won't be an issue.
  
I've also put in some plumbing to replace SecurityRealm.getUserPrincipals
and SecurityRealm.getGroupPrincipals with a new DeploymentSupport
interface. The GenericSecurityRealm can handle LoginModules that happen to
implement DeploymentSupport as well, or else you can give a class
implementing DeploymentSupport to the realm (though there's no way to
configure it then, so this needs more thought).  I've updated the file
properties realm to implement DeploymentSupport as an example.  FYI, the
DeploymentSupport class handles automapping as well, by providing a list
of automap principal classes for the login domain.

I also consolidated the SQL and File Principal classes down to a single
GeronimoUserPrincipal and GeronimoGroupPrincipal -- since we're
identifying login domains by name, and we plan to accomodate multiple
copies of the same login module (for different login domains) in a single
security realm (e.g. 2 different LDAP servers), the principal class will
only be used to distinguish principals of the same name within a single
login domain, and we don't need separate principal classes across login
modules.

I also changed the login service so it returns principals generated by
server-side login modules to the client and the JaasLoginCoordinator puts
them into the Subject (not RealmPrincipals, though).  This is controlled
by a new GBean attribute on the realm.  Note that the J2EE containers will
still need to call ContextManager.getServerSideSubject in order to get the
RealmPrincipals -- though we may want to handle that "automagically" in
the JaasLoginCoordinator when it is actually run on the server side.

Finally, I added a simple auditing login module and some tests with two
login modules in place.

Aaron