thanks for explaining this all to me. i could swear that SCRAM-SHA-256 was giving me the error, but like you i tried to reproduce it again and could not. i must have tested poorly, not waited for some settings to take effect or was looking at prior results. sorry to take up your time. It does seem to be working as i would expect it.
i did notice that many of the methods where deprecated which is why i was leaning towards the SCRAM-SHA-256. which Auth Provider would you say is the most secure and permits me to manage users and store passwords LOCALLY, within qpid? I also am seeing so many things that behave differently or just dont work if there is not SSL involved. I think this is great. for local DEV and POC work self signed certs can be annoying. So i dug around a little and realized i can use a self signed cert that QPID made for me and just include "transport.trustAll=true" in my connection string. this will give me a little more confidence that i am working towards a desired set up full of SSL even though im stuck using self-signed this early in our dev. thanks On Sat, Mar 11, 2017 at 6:44 AM Robbie Gemmell <robbie.gemm...@gmail.com> wrote: > 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 <danlangf...@gmail.com> 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: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
