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

[sweber42]

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
susan

[ovidiu.feodorov]

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.

[sweber42]

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(
 "org.jboss.security.ClientLoginModule",
 AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
 options)};
 return entries;
 }
 public void refresh() {}
}

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

<?xml version="1.0" encoding="UTF-8"?>
<server>
 <loader-repository>jboss.messaging:loader=ScopedLoaderRepository
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 <mbean code="org.jboss.jms.server.destination.Queue"
 name="jboss.messaging.destination:service=Queue,name=trisAuditQueue"
 xmbean-dd="xmdesc/Queue-xmbean.xml">
 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
 <attribute name="SecurityConfig">
 <security>
 <role name="IRT_TRUSTED" read="true" write="true" create="true"/>
 </security>
 </attribute>
 </mbean>
</server>

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

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

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

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

Let me know whether this sufficiently clarifies my situation.

thanks
susan

[sweber42]

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.

[sweber42]

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.