Qpid
  1. Qpid
  2. QPID-2979

The following SASL mechanisms [PLAIN] specified by the client are not supported by the broker

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.8
    • Fix Version/s: 0.9
    • Component/s: C++ Broker, Java Client
    • Labels:
      None
    • Environment:

      Windows XP

      Description

      An exception is thrown when connecting from a Java client (v 0.8) to qpidd (v 0.8) run with "--auth no".

      javax.jms.JMSException: Error creating connection: The following SASL mechanisms [PLAIN] specified by the client are not supported by the broker
      at org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:286)

      Used JNDI/JMS configuration:

      java.naming.factory.initial = org.apache.qpid.jndi.PropertiesFileInitialContextFactory
      connectionfactory.qpidConnectionfactory = amqp://guest:guest@clientid/abcd?brokerlist='tcp://localhost:5672'
      destination.mainSend = direct://amq.direct//step.01

      It worked just fine in 0.6 but no success now in 0.8.

      The broker is from Contributed C++ Packages -> Windows Installer (http://www.riverace.com/qpid/qpidc-0.8-x86.msi)

      Logs from qpidd:

      C:Program Filesapache-qpidc-0.8bin>qpidd --auth no --log-enable info+ --log-enable trace+:amqp_0_10
      2010-12-15 11:42:48 info Management enabled
      2010-12-15 11:42:48 notice SASL disabled: No Authentication Performed
      2010-12-15 11:42:48 info Policy file not specified. ACL Disabled, no ACL checking being done!
      2010-12-15 11:42:48 error Failed to initialise SSL listener: The credentials supplied to the package were not recognized (........cpps
      rcqpidbrokerwindowsSslProtocolFactory.cpp:177)
      2010-12-15 11:42:48 notice Listening on TCP port 5672
      5672
      2010-12-15 11:42:48 notice Broker running
      2010-12-15 11:42:53 trace SENT 127.0.0.1:1786 INIT(0-10)
      2010-12-15 11:42:53 trace SENT [127.0.0.1:1786]: Frame[BEbe; channel=0; {ConnectionStartBody: server-properties=

      {qpid.federation_tag:V2:36:s tr16(96790865-dc5c-427a-affe-70d021653737)}

      ; mechanisms=str16

      {V2:9:str16(ANONYMOUS)}

      ; locales=str16

      {V2:5:str16(en_US)}

      ; }]

      Run it with the -t option:

      2010-12-15 11:45:56 trace SEND raiseEvent (v1) class=org.apache.qpid.broker.clientDisconnect
      2010-12-15 11:46:01 debug RECV [127.0.0.1:1794] INIT(0-10)
      2010-12-15 11:46:01 trace SENT 127.0.0.1:1794 INIT(0-10)
      2010-12-15 11:46:01 trace SENT [127.0.0.1:1794]: Frame[BEbe; channel=0; {ConnectionStartBody: server-properties=

      {qpid.federation_tag:V2:36:s tr16(96790865-dc5c-427a-affe-70d021653737)}

      ; mechanisms=str16

      {V2:9:str16(ANONYMOUS)}

      ; locales=str16

      {V2:5:str16(en_US)}

      ; }]
      2010-12-15 11:46:01 debug DISCONNECTED [127.0.0.1:1794]
      2010-12-15 11:46:01 trace SEND raiseEvent (v1) class=org.apache.qpid.broker.clientDisconnect

        Issue Links

          Activity

          Hide
          Robbie Gemmell added a comment -

          AnonymousSaslClientFactory#getMechanismNames needs to handle the props map being null. Looks ok other than that.

          Also agree that the 0-10 client restricting to PLAIN would seem a bit odd...

          Show
          Robbie Gemmell added a comment - AnonymousSaslClientFactory#getMechanismNames needs to handle the props map being null. Looks ok other than that. Also agree that the 0-10 client restricting to PLAIN would seem a bit odd...
          Hide
          Gordon Sim added a comment -
          Show
          Gordon Sim added a comment - review requested: https://reviews.apache.org/r/445/
          Hide
          Gordon Sim added a comment -

          A further question is why the 0-10 codepath defaults to only accepting PLAIN rather than allowing the underlying Sasl implementation to determine what is available (when no user defined preferences or restrictions are specified)?

          Show
          Gordon Sim added a comment - A further question is why the 0-10 codepath defaults to only accepting PLAIN rather than allowing the underlying Sasl implementation to determine what is available (when no user defined preferences or restrictions are specified)?
          Hide
          Gordon Sim added a comment -

          This patch provides an ANONYMOUS SaslClient implementation (the broker already seems to have a SaslServer).

          It also adds the factory to the dynamic list properties and registers all factories from AMQConnectionDelegate_0_10 as the registration only seems to happen for 0-8/0-9 paths at present.

          Show
          Gordon Sim added a comment - This patch provides an ANONYMOUS SaslClient implementation (the broker already seems to have a SaslServer). It also adds the factory to the dynamic list properties and registers all factories from AMQConnectionDelegate_0_10 as the registration only seems to happen for 0-8/0-9 paths at present.
          Hide
          Gordon Sim added a comment -

          I don't think either of those is a good solution.

          (1) The broker can't send nothing in the mechanism array as that means no mechanisms are supported and the sasl handshake that is required part of the AMQP connection handshake could not complete.

          (2) I'm not sure what you mean by having Java 'skip SASL negotiation'. It has to send a connection-start-ok anyway; all it needs to do is state ANONYMOUS in the mechanism the response can actually be empty if desired. The neatest way to do this is a simple SASL plugin.

          Show
          Gordon Sim added a comment - I don't think either of those is a good solution. (1) The broker can't send nothing in the mechanism array as that means no mechanisms are supported and the sasl handshake that is required part of the AMQP connection handshake could not complete. (2) I'm not sure what you mean by having Java 'skip SASL negotiation'. It has to send a connection-start-ok anyway; all it needs to do is state ANONYMOUS in the mechanism the response can actually be empty if desired. The neatest way to do this is a simple SASL plugin.
          Hide
          Rajith Attapattu added a comment -

          We could probably have two solutions
          1). If --auth no is specified, then the broker does not send anything in the SASL mechanism array to the client.
          2.) Or if the broker sends ANONYMOUS to the Java client it should just skip SASL negotiation.

          Not sure which option is better

          Show
          Rajith Attapattu added a comment - We could probably have two solutions 1). If --auth no is specified, then the broker does not send anything in the SASL mechanism array to the client. 2.) Or if the broker sends ANONYMOUS to the Java client it should just skip SASL negotiation. Not sure which option is better
          Hide
          Rajith Attapattu added a comment -

          The reason why this used to work before (0.6 release) was due to the Java client silently ignoring SASL negotiation if the broker does not support any of the SASL mechanism the client is configured to use.
          This IMO is a security issue and should be immediately highlighted via an exception.
          Therefore from 0.8 onwards the Java client now throws an exception if the client does not support any of the mechanisms offered by the broker.

          By default the Java client supports PLAIN - and it does not seem to support ANONYMOUS see #1

          [1] http://download.oracle.com/javase/6/docs/technotes/guides/security/sasl/sasl-refguide.html

          Show
          Rajith Attapattu added a comment - The reason why this used to work before (0.6 release) was due to the Java client silently ignoring SASL negotiation if the broker does not support any of the SASL mechanism the client is configured to use. This IMO is a security issue and should be immediately highlighted via an exception. Therefore from 0.8 onwards the Java client now throws an exception if the client does not support any of the mechanisms offered by the broker. By default the Java client supports PLAIN - and it does not seem to support ANONYMOUS see #1 [1] http://download.oracle.com/javase/6/docs/technotes/guides/security/sasl/sasl-refguide.html
          Hide
          Robbie Gemmell added a comment -

          Updating Fix For to an unreleased version instead of 0.6.

          Show
          Robbie Gemmell added a comment - Updating Fix For to an unreleased version instead of 0.6.
          Hide
          Steve Huston added a comment -

          Noting that the C++ broker is involved in this report as well.

          Show
          Steve Huston added a comment - Noting that the C++ broker is involved in this report as well.
          Hide
          Steve Huston added a comment -

          Comment from this thread in email before it got to JIRA, from Gordon Sim:

          Ok, as you can see the windows broker behaves slightly differently with
          --auth no, and only offers ANONYMOUS.

          Unfortunately at present there is no implementation of that mechanism
          for java (either in the SunSASL provider or explicitly provided by
          Qpid). It would not be difficult to add I imagine.

          Perhaps the behaviour of the windows broker in this regard has changed
          in 0.8, intentionally or otherwise. However I can't see any obvious
          change.

          It would be an easy fix on the broker side (the handling of PLAIN is
          still there for the auth=no case, just need to advertise the mech).

          ==============================================================

          Thus, there may be two issues here that are intersecting:

          1. The Java client doesn't do ANONYMOUS

          2. The C++ Windows broker doesn't offer PLAIN when --auth no is set (although from the jira report, it once did)

          Show
          Steve Huston added a comment - Comment from this thread in email before it got to JIRA, from Gordon Sim: Ok, as you can see the windows broker behaves slightly differently with --auth no, and only offers ANONYMOUS. Unfortunately at present there is no implementation of that mechanism for java (either in the SunSASL provider or explicitly provided by Qpid). It would not be difficult to add I imagine. Perhaps the behaviour of the windows broker in this regard has changed in 0.8, intentionally or otherwise . However I can't see any obvious change. It would be an easy fix on the broker side (the handling of PLAIN is still there for the auth=no case, just need to advertise the mech). ============================================================== Thus, there may be two issues here that are intersecting: 1. The Java client doesn't do ANONYMOUS 2. The C++ Windows broker doesn't offer PLAIN when --auth no is set (although from the jira report, it once did)

            People

            • Assignee:
              Gordon Sim
              Reporter:
              Ibisek
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development