Bug 996897 - InitialContext.list("") causes SaslException in clustered setup
InitialContext.list("") causes SaslException in clustered setup
Status: CLOSED DUPLICATE of bug 901248
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Remoting (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Enrique Gonzalez Martinez
Jitka Kozana
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 04:57 EDT by Hisanobu Okuda
Modified: 2015-04-01 03:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-20 05:03:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample.tar.gz (23.01 KB, application/x-gzip)
2013-08-14 05:15 EDT, Hisanobu Okuda
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker WFLY-4376 Major Resolved Incorrect callback handler used during authentication (SASL) 2017-02-03 15:52 EST

  None (edit)
Description Hisanobu Okuda 2013-08-14 04:57:20 EDT
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 05:12:41 EDT
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 05:15:56 EDT
Created attachment 786467 [details]
sample.tar.gz
Comment 3 David M. Lloyd 2013-08-14 12:52:51 EDT
Is there an upstream JIRA for this?
Comment 4 Ladislav Thon 2014-09-10 07:15:57 EDT
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 04:13:04 EST
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 05:03:48 EDT

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

Note You need to log in before you can comment on or make changes to this bug.