5 Replies Latest reply on Mar 6, 2006 8:03 PM by Louis

    JAAS fails when java2ClassLoadingCompliance=

    Louis Newbie

      I have a login module that works great for several applications in JBoss 3.2.3. However, I have a new application that I have to deploy with
      java2ClassLoadingCompliance="false"
      set in the jboss-web.xml file. This is due to some incompatibilities in the jakarta commons libraries in the tomcat web service (I need to use a newer version).

      When I leave the java2ClassLoadingCompliance as "true" (the default in JBoss 3.2.3) it works fine, my login module is initialized when I deploy the application and authentication works. But as soon as I set it to false and redeploy, the login module is never called and it invisibly fails all authentication attempts. That is, I can see that the login failed, but I don't get any of my login modules logging output in the console. It's as if it doesn't see the existing JAASSecurityManager and/or SecurityManagerService.

      I've tried using the org.jboss.security.auth.login.DynamicLoginConfig but that throws a class not found exception (Is it not implemented in 3.2.3 or is it blocked by my java2ClassLoadingCompliance="false"?)

      All I need to do is be able to reconnect with the JAAS Security manager that's configured and ready to go (and works with the other applications). I don't have a particular need for a new and different Security manager. How can I tell jboss to reconnect this?

      I've also attempted to include my own JAAS Security manager in a login-service.xml file, but that fails with a NameAlreadyBoundException.

       <!-- JAAS security manager and realm mapping -->
       <mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
       name="example.laj.ca:service=JaasSecurityManager">
       <attribute name="SecurityManagerClassName">
       org.jboss.security.plugins.JaasSecurityManager
       </attribute>
       <attribute name="DefaultCacheTimeout"><!-- seconds -->
       30
       </attribute>
       </mbean>
      

      I get the name exception with other name= values:
      name="jboss.security:service=JaasSecurityManager"
      name="jboss.security:service=JaasSecurityManagerOther"
      name="example.laj.ca:service=JaasSecurityManagerOther"

      P.S. I saw in another issue this was caused by the inclusion of jboss libraries in the application. I did an audit of my files and I'm absolutely certain that I have no jboss files in the application. I do however have some jakarta commons files as I'm using struts.

        • 1. UPDATED: JAAS fails when java2ClassLoadingCompliance=false
          Louis Newbie

          I've expanded on my explanation of what's going on and posted complete server configuations on my web-site. One configuration leaves java2ClassLoadingCompliance=true (and uses the users/roles login module) and the other only switches java2ClassLoadingCompliance=false and then the login doesn't work. Please see it for more information:
          http://laj.ca:8080/jboss/

          I can't leave java2ClassLoadingCompliance=true, because I'm relying on some newer aspects of the commons-beanutils package. This isn't demonstrated in the posted example application as it isn't directly a component of the problem.

          • 2. Re: JAAS fails when java2ClassLoadingCompliance=
            chris griffith Expert

            louisaj,

            Where are your login modules stored?

            • 3. Re: JAAS fails when java2ClassLoadingCompliance=
              Louis Newbie

              The example doesn't use custom login modules. It's just using the UserNamePassword login module in the jboss login-config.xml file. My production system is using a custom login module, but the results are the same in both setups, so I'm reasonably certain that the behaviour isn't due to my custom module.

              The application is accessing the jaas configuation in the normal way via the jboss-web.xml file:

              <security-domain>java:/jaas/other</security-domain>

              This calls the default application-policy in the login-config.xml which is configured to use the UsersRolesLoginModule by default.

              The whole application is the expanded struts-blank.war folder in the deploy directory.

              The login modules themselves are presumably stored somewhere in the jboss class library heirarchy.

              • 4. Re: JAAS fails when java2ClassLoadingCompliance=
                Louis Newbie

                P.S. The code from the login-config.xml:

                 <application-policy name = "other">
                 <!-- A simple server login module, which can be used when the number
                 of users is relatively small. It uses two properties files:
                 users.properties, which holds users (key) and their password (value).
                 roles.properties, which holds users (key) and a comma-separated list of
                 their roles (value).
                 The unauthenticatedIdentity property defines the name of the principal
                 that will be used when a null username and password are presented as is
                 the case for an unuathenticated web client or MDB. If you want to
                 allow such users to be authenticated add the property, e.g.,
                 unauthenticatedIdentity="nobody"
                 -->
                 <authentication>
                 <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
                 flag = "required" />
                 </authentication>
                 </application-policy>
                

                This is unmodified from the default configuration.

                • 5. Re: JAAS fails when java2ClassLoadingCompliance=
                  Louis Newbie

                  I'm wondering if, with java2ClassLoadingCompliance set to false (this can be done either globablly or in the jboss-web.xml file, the result is the same for the application and login configuration), is there a need to explicitly call the login configuration mbean. How would I do that, and would single sign on still work?