Unless I'm misunderstanding something, there seems to be a serious flaw in the way JBoss expects JAAS login modules to implement the mapping between a javax.security.auth.Subject and J2EE security roles.
The expectation seems to be that JAAS login modules will populate the Subject with a special java.security.acl.Group named "Roles", each member of which is a java.security.Principal whose name matches a J2EE security role name. There are three serious problems with this scheme:
1.) This is not standard behaviour for a JAAS login module, so it precludes the use of the standard login modules that were not written with JBoss in mind. For this reason, such a module would not be portable across application servers, either.
2.) J2EE security roles are scoped to the J2EE module (WAR / EJB-JAR) level . One would typically wish to authenticate some or all applications against a corporate LDAP, NT, Kerberos realm etc. Given that multiple J2EE deployment units can coexist, attempting to merge all their security role names within a single security domain presents the possibility of namespace collisions and ambiguities that arise because the deployment context is not obvious; for example, does "administrators" refer to administrators of the payroll application, or of the MRP system?
3.) Pushing responsiblity for such mappings to the LoginModule and thence to the underlying security realm is not viable in any production scenario. For example, the administrator of a corporate LDAP realm would not wish to polllute the directory with application-specific attributes from multiple applications.
Other application servers typically achieve the J2EE security role : JAAS Principal mapping in an app.server-specific deployment descriptor. For example, weblogic places <security-role-assignment> elements in the weblogic-ejb-jar.xml for each EJB deployment. I venture to suggest that this is a more robust and viable approach.
