Uploaded image for project: 'Geronimo'
  1. Geronimo
  2. GERONIMO-1602

Switching from Tomcat causes error in JAAS module: "Unable to instantiate login module"

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1.x
    • Component/s: security, Tomcat
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat, .zip)

      Description

      I have a problem with porting a Tomcat application to Geronimo. The error stacktrace is attached.
      I deployed the war without any deployment plan and the app seams to be working (JSPs work and the startup-servlet works as well)
      But the JAASLoginModule was missing, so I could not log in. -> so far no Problem!
      Afterwards I configured a security realm with the console and after a restart my app does not complain about a missing LoginModule but throws the attached error stacktrace.
      For Tomcat I do the following:
      in catalina.properties I set

      #######JAAS
      java.security.auth.login.config=$

      {catalina.base}

      /conf/login.config

      and the login.config looks like this:

      MyApp {
      de.jato.security.auth.module.JatoServletLoginModule Sufficient loginServlet="/login/login.jsp";
      };

      I tried to use a special geronimo-web.xml where I set the
      <context-priority-classloader>true</context-priority-classloader>
      But I still get the same error:
      javax.security.auth.login.LoginException: org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate login module

      Caused by: java.lang.ClassNotFoundException: de.jato.security.auth.module.JatoServletLoginModule

      Am I doing something wrong? The class is in the war I deployed, and everything works fine in Tomcat.

        Issue Links

          Activity

          Hide
          djencks David Jencks added a comment -

          This is a known problem, that gbeans in a web plan cannot use the classes in the war, and in fact the war classes are not in the configuration classloader. The only solution at the moment is to move or copy the classes to a jar outside the war and use a dependency element to that jar in the plan that contains the login gbeans.

          We might be able to solve this problem in the 1.1 release but the code is not yet written.

          See GERONIMO-289

          Show
          djencks David Jencks added a comment - This is a known problem, that gbeans in a web plan cannot use the classes in the war, and in fact the war classes are not in the configuration classloader. The only solution at the moment is to move or copy the classes to a jar outside the war and use a dependency element to that jar in the plan that contains the login gbeans. We might be able to solve this problem in the 1.1 release but the code is not yet written. See GERONIMO-289
          Hide
          karstenvoges Karsten Voges added a comment -

          thanks for clarifying and providing a workaround. Still, I am looking forward to a general solution.

          Show
          karstenvoges Karsten Voges added a comment - thanks for clarifying and providing a workaround. Still, I am looking forward to a general solution.
          Hide
          ammulder Aaron Mulder added a comment -

          The issue that David Jencks was talking about was resolved in Geronimo 1.1. But I'm not sure how adding the classes to the web application will help make them available to the security realm. Karsten, can you confirm whether you still have a problem in Geronimo 1.1?

          Show
          ammulder Aaron Mulder added a comment - The issue that David Jencks was talking about was resolved in Geronimo 1.1. But I'm not sure how adding the classes to the web application will help make them available to the security realm. Karsten, can you confirm whether you still have a problem in Geronimo 1.1?
          Hide
          vamsic Vamsavardhana Reddy added a comment -

          I have tested the following scenario in server built from branches\1.1.

          I have created a login module (MyOwnLoginModule) & a principal class (MyPrincipal) and placed the jar in WEB-INF\lib directory. I have added a security realm gbean to geronimo-web.xml and configured the application to authenticate against this realm. The application deploys and runs fine. If I use GeronimoUserPrincipal in the login-module class and in role-mapping the security part works fine. Problem is with using "MyPrincipal". The login is succeeding, but, the authorization is not working as expected. I guess the problem is due to classLoaders.

          Having the loginmodule and principal classess in WEB-INF\classes dir or in a jar under WEB-INF\lib did not make a difference.

          Show
          vamsic Vamsavardhana Reddy added a comment - I have tested the following scenario in server built from branches\1.1. I have created a login module (MyOwnLoginModule) & a principal class (MyPrincipal) and placed the jar in WEB-INF\lib directory. I have added a security realm gbean to geronimo-web.xml and configured the application to authenticate against this realm. The application deploys and runs fine. If I use GeronimoUserPrincipal in the login-module class and in role-mapping the security part works fine. Problem is with using "MyPrincipal". The login is succeeding, but, the authorization is not working as expected. I guess the problem is due to classLoaders. Having the loginmodule and principal classess in WEB-INF\classes dir or in a jar under WEB-INF\lib did not make a difference.
          Hide
          vamsic Vamsavardhana Reddy added a comment -

          In continuation to my previous comment, I tried loading MyPrincipal in the same classloader as GeronimoUserPrincipal. Even that didn't help :o( I am sure it is a classloader problem. The code where the principals are to be matched has problems. I have put a println() in MyPrincipal.equals() method but it was never called. I think the principal is getting rejected even before the name is to be compared.

          Show
          vamsic Vamsavardhana Reddy added a comment - In continuation to my previous comment, I tried loading MyPrincipal in the same classloader as GeronimoUserPrincipal. Even that didn't help :o( I am sure it is a classloader problem. The code where the principals are to be matched has problems. I have put a println() in MyPrincipal.equals() method but it was never called. I think the principal is getting rejected even before the name is to be compared.
          Hide
          karstenvoges Karsten Voges added a comment -

          Sorry for not replying earlier. I have switched companies, so I cannot test the problem anymore. Sorry.

          Show
          karstenvoges Karsten Voges added a comment - Sorry for not replying earlier. I have switched companies, so I cannot test the problem anymore. Sorry.
          Hide
          djencks David Jencks added a comment -

          I think the code and classloaders surrounding this problem have changed enough so that the report is no longer relvant. No one seems to have complained about similar problems recently.

          Show
          djencks David Jencks added a comment - I think the code and classloaders surrounding this problem have changed enough so that the report is no longer relvant. No one seems to have complained about similar problems recently.

            People

            • Assignee:
              Unassigned
              Reporter:
              karstenvoges Karsten Voges
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development