On 11 March 2017 at 22:35, Dan Langford <danlangf...@gmail.com> wrote:
> 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? > > Of the available methods in the Java Broker, SCRAM-SHA-256 is the one I would recommend if you want the broker to manage the users/passwords yourself and store them through the broker. One consideration is that some of the non-Java clients don't support SCRAM-SHA-256 because they use the Cyrus SASL libraries, which only support SCRAM-SHA-1. If you plan to use any of those clients then I'd suggest SCRAM-SHA-1. > I also am seeing so many things that behave differently or just don't work > if there is not SSL involved. The broker deliberately doesn't allow plain text passwords over non-TLS connections (unless you explicitly disable these protections). > 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. > I'd certainly encourage using SSL/TLS in all environments. We included the auto-generating self-signed key store for precisely this purpose, to allow TLS to be configured in dev environments without having to procure a certificate authority. -- Rob > > 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 > > > > >
