4 Replies Latest reply on Oct 15, 2006 12:22 PM by sweber42

    JAAS login module - client jar incompatibility w/ jbosssx-cl

    sweber42 Newbie

      I had no trouble patching my JBossAS to use Messaging today, and it's looking promising to resolve our performance issues with large queues.

      However, I seem to be a bit stuck getting Messaging to play nice with the JAAS security scheme for my client. In the client build, when I replace jbossall-client.jar with jboss-messaging-client.jar, I get a ClassNotFoundException on org.jboss.security.ClientLoginModule. When I add jbosssx-client.jar to the client's classpath, I trigger the

      org.jboss.proxy.ClientContainer (no security manager: RMI class loader disabled)

      error message that I gather means there's a client library classloader incompatibility between the two client jars.

      Any chance of you making available a version of jbosssx-client.jar that works with Messaging? Or is there some workaround for this problem you could point me to?

      many thanks

        • 1. Re: JAAS login module - client jar incompatibility w/ jbosss
          Ovidiu Feodorov Master

          Could you please post the whole stack trace? I cannot figure out too much from what I've seen so far.

          Maybe a short test that I can replicate locally? I am specifically interested in how you use JAAS in conjunction with the JMS Connection.

          • 2. Re: JAAS login module - client jar incompatibility w/ jbosss
            sweber42 Newbie

            The stack trace is

            Caused by: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.ClientLoginModule
             at javax.security.auth.login.LoginContext.invoke(LoginContext.java:711)
             at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
             at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
             at java.security.AccessController.doPrivileged(Native Method)
             at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
             at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
             at edu.stanford.irt.mercury.authentication.ProgrammaticLogin.login(ProgrammaticLogin.java:64)
             at edu.stanford.irt.mercury.authentication.LoginDialog.doLogin(LoginDialog.java:311)

            where line 64 of ProgrammaticLogin is simply "lc.login()":

            62 Configuration.setConfiguration(new DefaultJaasConfiguration());
            63 lc = new LoginContext(getContextName(), getCallbackHandler());
            64 lc.login();

            The configuration is where the reference to org.jboss.security.ClientLoginModule is coming from:

            protected class DefaultJassConfiguration extends Configuration {
             public AppConfigurationEntry[] getAppConfigurationEntry(String arg0) {
             Map options = new HashMap();
             AppConfigurationEntry[] entries =
             new AppConfigurationEntry(
             return entries;
             public void refresh() {}

            Here's a sample deployment descriptor for one of our secured queues:

            <?xml version="1.0" encoding="UTF-8"?>
             <mbean code="org.jboss.jms.server.destination.Queue"
             <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
             <attribute name="SecurityConfig">
             <role name="IRT_TRUSTED" read="true" write="true" create="true"/>

            where IRT_TRUSTED is set in this login module in login-config.xml

             <application-policy name = "IrtHeadless">
             <login-module code="edu.stanford.irt.security.TrisX509LoginModule"
             <module-option name="keyStorePath">path_to_keystore</module-option>
             <module-option name="keyStorePassword">password</module-option>
             <module-option name="defaultRole">IRT_TRUSTED</module-option>

            and I've modified messaging-service.xml as follows

             <attribute name="SecurityDomain">java:/jaas/IrtHeadless</attribute>
             <attribute name="DefaultSecurityConfig">
             <role name="IRT_TRUSTED" read="true" write="true" create="true"/>

            Let me know whether this sufficiently clarifies my situation.


            • 3. Re: JAAS login module - client jar incompatibility w/ jbosss
              sweber42 Newbie

              I've come up with a workaround of sorts-- I've rewritten my build to produce a stripped down jar that contains only the server side JAAS login module, so I can deploy that to a standalone JBoss Messaging server for the queues we use in the HL7 message pipeline. This was our critical need, so I'm pretty happy with my solution.

              However, as far as I can tell, if I want to upgrade the queues used in our application server, the one that has a custom JAAS-authentication scheme for the fat client (we integrate with the univerity's Kerberos server), I would need to bring up a parallel instance of JBoss Messaging and rewrite the internals of my server application to have the queues hosted externally. I'm just going to wait for JBoss 5-- I have to assume that the missing client security classes will become available in the integrated release. Seems to me to be something of a gap.

              • 4. Re: JAAS login module - client jar incompatibility w/ jbosss
                sweber42 Newbie

                Turns out the real workaround is quite simple. I hand-created a jar file consisting of only the classes in org.jboss.security in jbosssx-client.jar, and called it orgJbossSecurity.jar. I then add orgJbossSecurity.jar and jboss-client.jar to my client classpath, and hey presto, I can both log in as a fat client to my JAS hosted secure application and use my custom-JAAS secured queues on the standalone JBoss Messaging instance. This was required for the last step of the message processing pipeline. I imagine the same tactic will work if I upgrade my main application server to JBoss Messaging as well, so maybe I don't have to wait for JBoss 5 after all.