6 Replies Latest reply on Aug 18, 2010 4:47 AM by sdawoodi

    Problem with custom login modules

    mmoyses

      On a recent support case the costumer is using IBM's Kerberos login module which was working fine in JBoss AS 4.0.4. Now he migrated to JBoss AS 4.2.0 and the login module fails with this stack trace:

      javax.security.auth.login.LoginException: Bad JAAS configuration: unrecognized option: jboss.security.security_domain
      at com.ibm.security.jgss.i18n.I18NException.throwLoginException(I18NException.java:7)
      at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:622)
      at com.ibm.security.auth.module.Krb5LoginModule.a(Krb5LoginModule.java:416)
      at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:238)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.lang.reflect.Method.invoke(Method.java:615)
      at javax.security.auth.login.LoginContext.invoke(LoginContext.java:795)
      at javax.security.auth.login.LoginContext.access$000(LoginContext.java:209)
      at javax.security.auth.login.LoginContext$4.run(LoginContext.java:709)
      at java.security.AccessController.doPrivileged(AccessController.java:242)
      at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:706)
      at javax.security.auth.login.LoginContext.login(LoginContext.java:603)
      at

      This option is related to this jira issue: http://jira.jboss.com/jira/browse/JBAS-1477

      To resolve this issue AuthenticationInfo now puts an extra entry in all login modules options map to set the security-domain name.
      This extra entry is not recognized as a valid option in this specific login module thus the exception. The problem is specific to this particular login module but could lead to problems in others as well.
      A proposed solution could be modify the security-config schema so that an extra attribute is included in the <login-module> element. This attribute should be a boolean indicating if the login module accepts the security-domain name entry in the options map. The attribute should not be required and defaults to true, this way everything keeps working as they are. Whenever this problem occurs, the costumer has the option to set this attribute to false so that AuthenticationInfo doesn't put the entry in the map.

        • 1. Re: Problem with custom login modules
          anil.saldhana

           

          (3:59:29 PM) Marcus: stefan and I were discussing our options in the kerberos case and we came up with 3 options... do you have time now to talk about it?
          (3:59:35 PM) anil_msn: k
          (4:00:10 PM) Marcus: option 1 is to remove the debug message (undo the jira issue)
          (4:01:20 PM) Marcus: option 2 is to assume only jboss login modules will have that option, so we filter the login modules by the class name and only add the option to the map if the package is org.jboss.security
          (4:03:13 PM) Marcus: option 3 we modify the security_config.xsd to add an attribute to the <login-module> element to specify if the login module accepts the debug option. this attribute will not be required and defaults to true. in a rare case like this, the costumer can set this attribute to false so that the option will not be added to the map
          (4:05:15 PM) anil_msn: I was thinking about option 2 in the afternoon
          (4:05:38 PM) anil_msn: but I think we need option 3 because customers who have written their own login module can get the sec domain
          (4:08:18 PM) Marcus: option 3 is probably the best in our opinion. everything keeps working as it is and only in the rare occasion where a custom login module has this problem we have a workaround
          (4:09:45 PM) Marcus: with option 2, custom login modules that extend one of our own will print null for the config name, because the option will not be in the map


          • 2. Re: Problem with custom login modules
            sguilhen

            When Marcus and I discussed this issue earlier today, we first considered adding some kind of check (for example, to make sure the login module is not the IBM Kerberos LM) in the AuthenticationInfo class before setting the security-domain name option, to avoid this kind of problem. This approach has a clear downside: if later on we find out about another login module that doesn't accept extra options, we will have to change our check and the code will have to be re-compiled.

            Thus, I think the approach Marcus is suggesting is better, as it will allow users to specify that they don't want security domain name to be automatically inserted as a module option in the configuration file. This way, no code has to re-compiled or changed.

            • 3. Re: Problem with custom login modules
              anil.saldhana

              This is basically a workaround to deal with morons while writing login modules get choked with additional module options (that they do not know about).

              You are given a map of options. Just take the ones you want and ignore the rest. Why is that difficult?

              I think a bug report should be filed with the IBM JDK.

              • 4. Re: Problem with custom login modules
                mmoyses
                • 5. Re: Problem with custom login modules
                  anil.saldhana

                  Marcus, let me take a look at how the module option semantics were weaved into get into all login modules before you proceed.

                  We can also use a system property which turns of this module option being added to login modules. This is the simplistic approach.

                  UPDATE: This issue has been fixed via a system property (that will disable the addition of the security domain via the module option).

                  • 6. Re: Problem with custom login modules
                    sdawoodi

                    What is the system property and what to set to? I am currently migrating our EJB2 based app from JBoss 4.0.3SP1 to 5.0.1.

                     

                    Appreciate your helping me out here.