I have a web application with security constraints defined in web.xml, but without jboss-web.xml, so the default security domain 'other' is used for the authentication. I wanted to add an additional role to all authenticated users, so I added a mapping module to the configuration of the security domain: /subsystem=security/security-domain=other/mapping=classic:add /subsystem=security/security-domain=other/mapping=classic/mapping-module=mapRoleToAllUsers:add(code="org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider", type="role", module-options=[("dsJndiName"=>"java:jboss/datasources/ExampleDS"), ("rolesQuery"=>"SELECT 'Admin' FROM Dual WHERE ?!=''")]) reload The mapping module is correctly initialized - DatabaseRolesMappingProvider.init(Map) finishes successfully. Nevertheless the mapping is not performed because the JBossAuthorizationManager is not able to retrieve the MappingContext. If the jboss-web.xml is not used, then null is returned on line 366 in org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(Principal, Subject, SecurityContext): MappingContext<RoleGroup> mc = mm.getMappingContext(MappingType.ROLE.name()); on Using a simple jboss-web.xml with security domain name fixes the mapping issue, but it means to edit deployed applications. This is obviously not desirable state. Sample of jboss-web.xml: <jboss-web> <security-domain>other</security-domain> </jboss-web>
When the jboss-web.xml is present the call stack seems like: [1] org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider.performMapping (DatabaseRolesMappingProvider.java:86) [2] org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider.performMapping (DatabaseRolesMappingProvider.java:42) [3] org.jboss.security.mapping.MappingContext.performMapping (MappingContext.java:54) [4] org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles (JBossAuthorizationManager.java:386) [5] org.jboss.security.plugins.JBossAuthorizationManager.getSubjectRoles (JBossAuthorizationManager.java:314) [6] org.jboss.as.web.security.JBossWebRealm.authenticate (JBossWebRealm.java:232) [7] org.apache.catalina.authenticator.FormAuthenticator.authenticate (FormAuthenticator.java:280) [8] org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:391) [9] org.jboss.as.web.session.ClusteredSessionValve.handleRequest (ClusteredSessionValve.java:134) [10] org.jboss.as.web.session.ClusteredSessionValve.invoke (ClusteredSessionValve.java:99) [11] org.jboss.as.web.session.JvmRouteValve.invoke (JvmRouteValve.java:92) [12] org.jboss.as.web.session.LockingValve.invoke (LockingValve.java:64) [13] org.jboss.as.web.security.SecurityContextAssociationValve.invoke (SecurityContextAssociationValve.java:169) [14] org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:145) [15] org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:97) [16] org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:102) [17] org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:336) [18] org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:856) [19] org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process (Http11Protocol.java:653) [20] org.apache.tomcat.util.net.JIoEndpoint$Worker.run (JIoEndpoint.java:926) [21] java.lang.Thread.run (Thread.java:744)
I have researched necessary changes to the code. Modification of fallback security domain behaviour will be quite risky to put to the 6.4.0. This issue can hardly happen in production as user have to have their own security domain defined and selected through jboss-web.xml. Quite easy workaround is possible as well (create jboss-web.xml). We won't fix this issue.