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
