On 15 March 2017 at 03:30, Dan Langford <[email protected]> wrote:
> Thanks for the heads up. On our other Qpid install we have played with this > .Net library https://github.com/Azure/amqpnetlite/blob/master/README.md > which only supports PLAIN, EXTERNAL, and ANONYMOUS. I also know we did a > NodeJS POC with the noodledrenzy library which looks like it also only > supports PLAIN and ANONYMOUS > https://github.com/noodlefrenzy/node-amqp10/blob/master/lib/sasl.js > > Couple questions: what libraries are people using for .Net and nodejs > connections? Also since I am now doing everything over SSL, even local Dev, > will the broker allow the PLAIN sasl mechanism against the SCRAM-SHA-256 > Auth Provider? Yes - when using SSL the SCRAM-SHA-256 auth provider will offer the PLAIN mechanism, so pretty much every client should work. -- Rob > Or am I misunderstanding the relationship between a SASL > Mechanism and an Auth Provider? > > As always thanks for your time > > On Sat, Mar 11, 2017 at 4:07 PM Rob Godfrey <[email protected]> > wrote: > > On 11 March 2017 at 22:35, Dan Langford <[email protected]> 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 <[email protected] > > > > 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 <[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] > > > > > > > > >
