glassfish
  1. glassfish
  2. GLASSFISH-20364

BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1
    • Component/s: security
    • Labels:
      None
    • Environment:

      security-devtests-trunk

      Description

      The jdbcrealm security devtest is failing to configure the auth-realm:

      create-custom-auth-realm:
      [echo] Creating auth realm JDBCRealm_SHA_BASE64 ...
      [exec] asadmin --host localhost --port 4848 --user admin --passwordfile /scratch/crperez/gf/v2/appserv-tests/config/adminpassword.txt --interactive=false --echo=true --terse=true create-auth-realm --classname com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm --property datasource-jndi=jdbc/MyWhirlPool:jaas-context=jdbcRealm:db-user=dbuser:db-password=dbpass:user-name-column=USERNAME:password-column=PASSWORD:group-table=GROUP_TABLE:group-name-column=GROUPNAME:user-table=USER_TABLE_SHA_BASE64:digest-algorithm=SHA:encoding=BASE64 --target server JDBCRealm_SHA_BASE64
      [exec] remote failure: Creation of Authrealm JDBCRealm_SHA_BASE64 failed. com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [211]
      [exec] com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [211]

        Issue Links

          Activity

          Hide
          Nithya Ramakrishnan added a comment -

          Committed revision 63139 for refactoring package names in JDBCRealm and PamRealm to remove the ee parts.
          Made changes in security devtests to take this JDBCRealm package name ("com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm)

          Show
          Nithya Ramakrishnan added a comment - Committed revision 63139 for refactoring package names in JDBCRealm and PamRealm to remove the ee parts. Made changes in security devtests to take this JDBCRealm package name ("com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm)
          Hide
          Sanjeeb Sahoo added a comment -

          If there are no other bundles exporting com.sun.enterprise.security.auth.realm.jdbc and com.sun.enterprise.security.auth.realm.pam packages (You really need to search existing bundles to ensure this), then I don't see any issues in them being exported by appserver/core-ee/security bundle after necessary refactoring to remove "ee" from package names to restore compatibility.

          Show
          Sanjeeb Sahoo added a comment - If there are no other bundles exporting com.sun.enterprise.security.auth.realm.jdbc and com.sun.enterprise.security.auth.realm.pam packages (You really need to search existing bundles to ensure this), then I don't see any issues in them being exported by appserver/core-ee/security bundle after necessary refactoring to remove "ee" from package names to restore compatibility.
          Hide
          Nithya Ramakrishnan added a comment - - edited

          Adding the discussion over mail to the issue:
          JDBCRealm and PamRealm were moved out of nucleus/core/security to appserver/core-ee/security since they had a few dependencies that could not be part of the nucleus distro. Their package names were changed to have an ee appended during this refactoring.
          The primary reason why the old JDBCRealm's package name cannot be retained in the new location seems to be a possible
          split package issue. However, we seem to be exporting the fully qualified package name for every realm individually and every realm has a unique package structure too.

          For a closer look, here is the osgi.bundle's export-contents for nucleus/security/core:

          (Listing 1)

          -exportcontents: \
          com.iplanet.ias.security.auth.login; \
          com.sun.enterprise.security; \
          com.sun.enterprise.security.auth; \
          com.sun.enterprise.security.audit; \
          com.sun.enterprise.security.auth.login; \
          com.sun.enterprise.security.factory; \
          com.iplanet.ias.security.auth.realm; \
          com.sun.enterprise.security.auth.realm; \
          com.sun.enterprise.security.auth.realm.certificate; \
          com.sun.enterprise.security.auth.realm.file; \
          com.sun.enterprise.security.auth.realm.ldap; \
          com.sun.enterprise.security.auth.realm.solaris; \
          com.sun.enterprise.security.util; \
          com.sun.enterprise.common.iiop.security; \
          com.sun.enterprise.security.auth.digest.api; \
          com.sun.enterprise.security.auth.login.common; \
          com.sun.enterprise.security.common; \
          com.sun.logging.enterprise.system.core.security; \
          com.sun.enterprise.security.ssl; version=$

          {project.osgi.version}

          Contents of the osgi.bundle in appserver/security/core-ee:

          (Listing 2)

          -exportcontents: \
          com.sun.enterprise.security.acl; \
          com.sun.enterprise.security.ee; \
          com.sun.enterprise.security.ee.audit; \
          com.sun.enterprise.security.ee.auth.login; \
          <b> com.sun.enterprise.security.ee.auth.realm.jdbc; \</b>
          com.sun.enterprise.security.ee.authorize; \
          com.sun.enterprise.security.jauth; \
          com.sun.enterprise.security.jmac; \
          com.sun.enterprise.security.jmac.callback; \
          com.sun.enterprise.security.jmac.config; \
          <b> com.sun.enterprise.security.ee.auth.realm.pam; \</b>
          com.sun.enterprise.security.authorize; \
          com.sun.enterprise.security.provider; \
          com.sun.enterprise.security.auth.digest.impl; \
          com.sun.enterprise.security.perms; \
          com.sun.enterprise.security.web.integration;
          It has to be noted that the package com.sun.enterprise.security.ee.auth.realm is not exported here, though it has 2 classes related to Digest (they are used internally within the bundle).

          If the packages in bold in Listing 2 are changed to

          com.sun.enterprise.security.auth.realm.jdbc; \
          com.sun.enterprise.security.auth.realm.pam; \

          will it still cause the split package issue given that there is no second package name for the above in Listing 1.

          Show
          Nithya Ramakrishnan added a comment - - edited Adding the discussion over mail to the issue: JDBCRealm and PamRealm were moved out of nucleus/core/security to appserver/core-ee/security since they had a few dependencies that could not be part of the nucleus distro. Their package names were changed to have an ee appended during this refactoring. The primary reason why the old JDBCRealm's package name cannot be retained in the new location seems to be a possible split package issue. However, we seem to be exporting the fully qualified package name for every realm individually and every realm has a unique package structure too. For a closer look, here is the osgi.bundle's export-contents for nucleus/security/core: (Listing 1) -exportcontents: \ com.iplanet.ias.security.auth.login; \ com.sun.enterprise.security; \ com.sun.enterprise.security.auth; \ com.sun.enterprise.security.audit; \ com.sun.enterprise.security.auth.login; \ com.sun.enterprise.security.factory; \ com.iplanet.ias.security.auth.realm; \ com.sun.enterprise.security.auth.realm; \ com.sun.enterprise.security.auth.realm.certificate; \ com.sun.enterprise.security.auth.realm.file; \ com.sun.enterprise.security.auth.realm.ldap; \ com.sun.enterprise.security.auth.realm.solaris; \ com.sun.enterprise.security.util; \ com.sun.enterprise.common.iiop.security; \ com.sun.enterprise.security.auth.digest.api; \ com.sun.enterprise.security.auth.login.common; \ com.sun.enterprise.security.common; \ com.sun.logging.enterprise.system.core.security; \ com.sun.enterprise.security.ssl; version=$ {project.osgi.version} Contents of the osgi.bundle in appserver/security/core-ee: (Listing 2) -exportcontents: \ com.sun.enterprise.security.acl; \ com.sun.enterprise.security.ee; \ com.sun.enterprise.security.ee.audit; \ com.sun.enterprise.security.ee.auth.login; \ <b> com.sun.enterprise.security.ee.auth.realm.jdbc; \</b> com.sun.enterprise.security.ee.authorize; \ com.sun.enterprise.security.jauth; \ com.sun.enterprise.security.jmac; \ com.sun.enterprise.security.jmac.callback; \ com.sun.enterprise.security.jmac.config; \ <b> com.sun.enterprise.security.ee.auth.realm.pam; \</b> com.sun.enterprise.security.authorize; \ com.sun.enterprise.security.provider; \ com.sun.enterprise.security.auth.digest.impl; \ com.sun.enterprise.security.perms; \ com.sun.enterprise.security.web.integration; It has to be noted that the package com.sun.enterprise.security.ee.auth.realm is not exported here, though it has 2 classes related to Digest (they are used internally within the bundle). If the packages in bold in Listing 2 are changed to com.sun.enterprise.security.auth.realm.jdbc; \ com.sun.enterprise.security.auth.realm.pam; \ will it still cause the split package issue given that there is no second package name for the above in Listing 1.
          Hide
          Tim Quinn added a comment -

          Linking this to the original JIRA issue that uncovered the problem.

          This problem was mentioned in the release notes for 4.0 but the regular doc does need to be updated.

          Show
          Tim Quinn added a comment - Linking this to the original JIRA issue that uncovered the problem. This problem was mentioned in the release notes for 4.0 but the regular doc does need to be updated.
          Hide
          nabizamani added a comment -

          I am running GlassFish Server Open Source Edition 4.0 (build 89) and I have the same issue on our prod system! I get the following error message:

          com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [320]

          I believe that this is an absolute blocker as it prevents people from using jdbcRealms because they have no chance to find out which class to use!

          Page 1-39 of the Reference Manual (see https://glassfish.java.net/docs/4.0/reference-manual.pdf) states the following (just search for com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm in the pdf):

          [...]
          --classname
          Java class which implements this realm. These include
          [...]
          com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm,
          [...]

          I have tested with com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm and it seems to work.
          So your workaround with using com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm instead of com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm works fine, but the documentation should definitely be updated. This is also very important in order to make it clear and transparent which class shall be used!

          Show
          nabizamani added a comment - I am running GlassFish Server Open Source Edition 4.0 (build 89) and I have the same issue on our prod system! I get the following error message: com.sun.enterprise.security.auth.realm.BadRealmException: java.lang.ClassNotFoundException: com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm not found by org.glassfish.main.security [320] I believe that this is an absolute blocker as it prevents people from using jdbcRealms because they have no chance to find out which class to use! Page 1-39 of the Reference Manual (see https://glassfish.java.net/docs/4.0/reference-manual.pdf ) states the following (just search for com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm in the pdf): [...] --classname Java class which implements this realm. These include [...] com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm, [...] I have tested with com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm and it seems to work. So your workaround with using com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm instead of com.sun.enterprise.security.auth.realm.jdbc.JDBCRealm works fine, but the documentation should definitely be updated. This is also very important in order to make it clear and transparent which class shall be used!
          Hide
          Craig Perez added a comment -

          In order to resolve and get the tests running the JDBCRealm class name was update:

          <param name="realmclass" value="com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm"/>

          There may be upgrade or doc impacts to the change in class that needs further investigation.

          Show
          Craig Perez added a comment - In order to resolve and get the tests running the JDBCRealm class name was update: <param name="realmclass" value="com.sun.enterprise.security.ee.auth.realm.jdbc.JDBCRealm"/> There may be upgrade or doc impacts to the change in class that needs further investigation.

            People

            • Assignee:
              Nithya Ramakrishnan
              Reporter:
              Craig Perez
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: