Hi Dan, The client will emit the below if it either fails to find a matching SASL mechanism that both it and the server support, or if it isn't able to use any of the offered mechanisms because the avaialble credentials don't allow (e.g FOO etc mechs are offered and need a user/pass, but none was given).
By default the Java broker doesnt offer the PLAIN mechanism, even if the given authentication provider supports it, unless the port is using SSL. You can change this (more below), but in this case you probably shouldnt, and so another mechanism must be used instead. For the Base64MD5PasswordFile AuthenticationProvider, without SSL or the config to override the related behaviour then the broker only offers some custom CRAM-MD5-HASHED and CRAM-MD5-HEX mechanisms. None of the AMQP 1.0 clients support these old custom mechs, so the connection attempt failed because the client couldn't find an agreeable mechanism to use. This is the first reason it wont work with this auth provider currently, another coming later. Use of this auth provider isn't really advised however, and per the docs is considered deprecated: http://qpid.apache.org/releases/qpid-java-6.1.1/java-broker/book/Java-Broker-Security.html. For the SCRAM-SHA-256 provider, it only offers SCRAM-SHA-256 by default unless you use SSL or override the related behaviour to allow PLAIN. I was able to get this provider working without issue, since the client does support that mech. If I defined a user for the provider and used it, the connection succeeded, if I did not it failed as expected. I think your port config may not have been set to use the SCRAM-SHA-256 provider and could still have been actually using the Base64MD5PasswordFile provider? It would behave exactly as you describe if so. I mentioned that you can make the broker offer PLAIN when supported even without SSL, by editing the brokers config.json configuration file. See https://issues.apache.org/jira/browse/QPID-5922?focusedCommentId=14347696&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14347696 for example of this. This works for the three providers you have tried using, though the only one it should make any difference for with the JMS clietn is the Base64MD5PasswordFile since the SCRAM mechanisms will continue to be prefered for the other providers anyway. Unfortunately when I tried this I found that PLAIN support is broken with the Base64MD5PasswordFile provider in 6.1.1. It seems this was already noticed and fixed recently via https://issues.apache.org/jira/browse/QPID-7643, so that should work again in the next release. Robbie On 10 March 2017 at 22:11, Dan Langford <[email protected]> wrote: > *Software Versions* > Java Broker 6.1.1 > qpid-jms-client 0.20.0 > > > *When my Authentication Provider assigned to my AMQP port > is PlainPasswordFile then i am able to connect just fine:* > > *RemoteURI *amqp://<hostname>:5672?amqp.vhost=default > > [AmqpProvider:(1):[amqp://<hostname>:5672]] INFO > org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth > was: SASL-SCRAM-SHA-256 > [AmqpProvider:(1):[amqp://<hostname>:5672]] INFO > org.apache.qpid.jms.JmsConnection - Connection > ID:d03c3e30-63af-42bd-959b-a673c6da798f:1 connected to remote Broker: > amqp://<hostname>:5672 > Message sent: {"key1":"value1"} > > > *However when my Authentication Provider assigned to my AMQP port is set > to Base64MD5PasswordFile or SCRAM-SHA-256 i get this error on the client:* > > *RemoteURI *amqp://<hostname>:5672?amqp.vhost=default > > [AmqpProvider:(1):[amqp://<hostname>:5672]] INFO > org.apache.qpid.jms.sasl.SaslMechanismFinder - Best match for SASL auth > was: null > [main] ERROR org.apache.qpid.jms.JmsConnection - Failed to connect to > remote at: amqp://<hostname>:5672?amqp.vhost=default > > javax.jms.JMSSecurityException: Could not find a suitable SASL mechanism > for the remote peer using the available credentials. > > at > org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.handleSaslInit(AmqpSaslAuthenticator.java:145) > at > org.apache.qpid.jms.provider.amqp.AmqpSaslAuthenticator.authenticate(AmqpSaslAuthenticator.java:92) > at > org.apache.qpid.jms.provider.amqp.AmqpProvider.processSaslAuthentication(AmqpProvider.java:925) > at > org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:909) > at > org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1800(AmqpProvider.java:93) > at > org.apache.qpid.jms.provider.amqp.AmqpProvider$18.run(AmqpProvider.java:784) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > I presume there is some sort of config i am missing. Does this ring a bell? > Is there a direction i could be pointed in? maybe it has to do with the URL > pattern my client is using in the connection factory? or maybe i just > completely misunderstand how i should be configuring SASL mechanisms. > > thank you --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
