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 Sat, 11 Mar 2017 23:07:41 GMT
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