[
https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug...
]
Stefan Guilhen commented on SECURITY-930:
-----------------------------------------
[~ppalaga] Yeah, those two, in that order. The first one was ok if the PB upgrade and the
WF changes were both done at the same time. As it turned out, this was not possible, so we
had to update PicketBox first and then update WildFly to use the new API to register
multiple modules. So I had to rework the commit to make sure the ClassLoaderLocator API
was still compatible with the WF implementation.
I think backporting this should be perfectly possible. This is the WF commit that would
need to be backported to EAP after PicketBox is updated:
https://github.com/wildfly/wildfly/pull/9323/commits/88fbeb68a05da36362a4...
A security-domain can only load login-modules from a single JBoss
module
--------------------------------------------------------------------------
Key: SECURITY-930
URL:
https://issues.jboss.org/browse/SECURITY-930
Project: PicketBox
Issue Type: Bug
Components: JBossSX, Security-SPI
Reporter: Derek Horton
Assignee: Stefan Guilhen
Fix For: PicketBox_5_0_0.Beta1
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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)