qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: [Java Broker 6.1.1, qpid-jms-client 0.20.0] Best match for SASL auth was: null
Date Wed, 15 Mar 2017 06:59:46 GMT
On 15 March 2017 at 03:30, Dan Langford <danlangford@gmail.com> 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 <rob.j.godfrey@gmail.com>
> wrote:
>
> On 11 March 2017 at 22:35, Dan Langford <danlangford@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.gemmell@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 <danlangford@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message