Description of problem: Running EAP6 with standalone-full-ha.xml, when a remoting client invokes InitialContext.list(""), it shows SaslException. However it can list all the jndi entries in a remote machine, ERROR level message appears. Version-Release number of selected component (if applicable): EAP 6.1.0 How reproducible: Steps to Reproduce: 1. extract sample.tar.gz 2. copy application-roles.properties, application-users.properties, and standalone-full-ha.xml into $JBOSS_HOME/standalone/configuration 3. copy counter.jar into $JBOSS_HOME/standalone/deployment 4. run EAP6 # $JBOSS_HOME/bin/standalone.sh -c standalone-full-ha.xml -Djboss.node.name=node1 5. run a client # ./test.sh 6. you would see an ERROR message:- ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed Actual results: Expected results: Additional info:
Attaching a debugger, I found UnsupportedCallbackException is thrown. VM Started: No frames on the current call stack main[1] catch javax.security.auth.callback.UnsupportedCallbackException Deferring all javax.security.auth.callback.UnsupportedCallbackException. It will be set after the class is loaded. main[1] run > Set deferred all javax.security.auth.callback.UnsupportedCallbackException Exception occurred: javax.security.auth.callback.UnsupportedCallbackException (to be caught at: org.jboss.sasl.digest.DigestMD5Clie nt.processChallenge(), line=381 bci=536)"thread=Remoting "config-based-naming-client-endpoint" task-2", org.jboss.ejb.client.Defaul tCallbackHandler.handle(), line=47 bci=82 Remoting "config-based-naming-client-endpoint" task-2[1] where [1] org.jboss.ejb.client.DefaultCallbackHandler.handle (DefaultCallbackHandler.java:47) [2] org.jboss.sasl.digest.DigestMD5Client.processChallenge (DigestMD5Client.java:352) [3] org.jboss.sasl.digest.DigestMD5Client.evaluateChallenge (DigestMD5Client.java:235) [4] org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication$1.run (ClientConnectionOpenListener.java:609) [5] java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1,145) [6] java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:615) [7] java.lang.Thread.run (Thread.java:722) Remoting "config-based-naming-client-endpoint" task-2[1] locals Method arguments: callbacks = instance of javax.security.auth.callback.Callback[3] (id=1696) Local variables: arr$ = instance of javax.security.auth.callback.Callback[3] (id=1696) len$ = 3 i$ = 2 current = instance of javax.security.auth.callback.PasswordCallback(id=1697) Remoting "config-based-naming-client-endpoint" task-2[1] print callbacks[0] callbacks[0] = "javax.security.sasl.RealmCallback@4f7b9ed4" Remoting "config-based-naming-client-endpoint" task-2[1] print callbacks[1] callbacks[1] = "javax.security.auth.callback.NameCallback@403108f6" Remoting "config-based-naming-client-endpoint" task-2[1] print callbacks[2] callbacks[2] = "javax.security.auth.callback.PasswordCallback@33f0c408" Remoting "config-based-naming-client-endpoint" task-2[1] cont > The application exited The exception populates DIGEST-MD5 into failedMechs, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 608 try { 609 response = saslClient.evaluateChallenge(challenge); 610 } catch (Throwable e) { 611 final String mechanismName = saslClient.getMechanismName(); 612 client.debugf("Client authentication failed for mechanism %s: %s", mechanismName, e); 613 failedMechs.add(mechanismName); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and could be the cause of SaslException. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 343 if (serverSaslMechs.isEmpty()) { 344 connection.handleException(new SaslException("Authentication failed: all available authentication mechanisms failed")); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Created attachment 786467 [details] sample.tar.gz
Is there an upstream JIRA for this?
Is this possibly a duplicate of bug 901248? The symptoms seem to be the same -- "SaslException: Authentication failed: all available authentication mechanisms failed", but the actual call succeeds. Also, the customer issue is closed already.
This is a duplicate of BZ#901248 and it is related to the cluster topology messaging. That's the reason why when an ejb is invoked succeeds despite the stacktrace (they are not affected). Probably should be linked to that BZ as well.
*** This bug has been marked as a duplicate of bug 901248 ***