Bug 1280512
| Summary: | [GSS] (6.4.z) A security-domain can only load login-modules from a single JBoss module | |||
|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | dhorton | |
| Component: | Security | Assignee: | Peter Palaga <ppalaga> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Josef Cacek <jcacek> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 6.4.4 | CC: | anmiller, bdawidow, bmaxwell, darran.lofthouse, dtikhomi, ihradek, msochure, pjurak, ppalaga, pskopek | |
| Target Milestone: | CR1 | |||
| Target Release: | EAP 6.4.14 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1408458 (view as bug list) | Environment: | ||
| Last Closed: | 2017-03-23 08:25:30 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1408458 | |||
| Bug Blocks: | 1401452 | |||
The upstream PR https://github.com/wildfly/wildfly/pull/9508 adds a test case and should be backported together with https://github.com/wildfly/wildfly/pull/9323 Verified for EAP 6.4.14.CP.CR1; Released with EAP 6.4.14 on March 14 (ZIPs) and March 22 (RPMs). |
Description of problem: A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: <security-domain name="jmx-console" cache-type="default"> <authentication> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> </authentication> </security-domain> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests.