Bug 996897

Summary: InitialContext.list("") causes SaslException in clustered setup
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Hisanobu Okuda <hokuda>
Component: RemotingAssignee: Enrique Gonzalez Martinez <egonzale>
Status: CLOSED DUPLICATE QA Contact: Jitka Kozana <jkudrnac>
Severity: unspecified Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.1.0CC: bbaranow, cdewolf, egonzale, lthon, thofman
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-20 09:03:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sample.tar.gz none

Description Hisanobu Okuda 2013-08-14 08:57:20 UTC
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:

Comment 1 Hisanobu Okuda 2013-08-14 09:12:41 UTC
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"));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Comment 2 Hisanobu Okuda 2013-08-14 09:15:56 UTC
Created attachment 786467 [details]
sample.tar.gz

Comment 3 David M. Lloyd 2013-08-14 16:52:51 UTC
Is there an upstream JIRA for this?

Comment 4 Ladislav Thon 2014-09-10 11:15:57 UTC
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.

Comment 5 Enrique Gonzalez Martinez 2015-02-19 09:13:04 UTC
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.

Comment 7 Enrique Gonzalez Martinez 2015-03-20 09:03:48 UTC

*** This bug has been marked as a duplicate of bug 901248 ***