[jboss-jira] [JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module

[Stefan Guilhen (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated WFLY-7412:
---------------------------------
    Description: 
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.

  was:

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.



>  A security-domain can only load login-modules from a single JBoss module 
> --------------------------------------------------------------------------
>
>                 Key: WFLY-7412
>                 URL: https://issues.jboss.org/browse/WFLY-7412
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Stefan Guilhen
>
> 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.



--
This message was sent by Atlassian JIRA
(v7.2.2#72004)