Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
None
-
all
Description
The current implementation of clustering does not correctly handle authentication correctly. From the trunk build:
[kgiusti@localhost src]$ ./qpidd --auth yes --realm KGIUSTI.COM --log-enable info+ --load-module ./.libs/cluster.so --cluster-name ken
2009-11-02 10:30:58 info Loaded Module: ./.libs/cluster.so
2009-11-02 10:30:58 info Management enabled
2009-11-02 10:30:58 notice Initializing CPG
2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) membership change: 127.0.0.1:14581 (joined: 127.0.0.1:14581(joined) )
2009-11-02 10:30:58 info No message store configured, persistence is disabled.
2009-11-02 10:30:58 info SASL enabled
2009-11-02 10:30:58 notice Listening on TCP port 5672
2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 INIT) joining cluster ken with url=amqp:tcp:10.16.19.19:5672,tcp:10.16.14.69:5672,tcp:192.168.122.1:5672
2009-11-02 10:30:58 notice Broker running
2009-11-02 10:30:58 info cluster(127.0.0.1:14581 READY) member update: 127.0.0.1:14581(member)
2009-11-02 10:30:58 notice cluster(127.0.0.1:14581 READY) first in cluster
2009-11-02 10:31:05 info SASL: Mechanism list: ANONYMOUS PLAIN DIGEST-MD5 LOGIN GSSAPI CRAM-MD5
2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) new local connection 127.0.0.1:14581-1
2009-11-02 10:31:05 info SASL: Starting authentication with mechanism: GSSAPI
2009-11-02 10:31:05 info SASL: Authentication succeeded for: testuser@KGIUSTI.COM
2009-11-02 10:31:05 error cluster(127.0.0.1:14581 READY) aborting connection 127.0.0.1:14581-1: framing-error: Reserved bits not zero (qpid/framing/AMQFrame.cpp:132)
2009-11-02 10:31:05 info cluster(127.0.0.1:14581 READY) connection closed 127.0.0.1:14581-1
The above error occurs when running perftest against the cluster in the following manner:
[kgiusti@localhost tests]$ /usr/kerberos/bin/kinit testuser@KGIUSTI.COM
[kgiusti@localhost tests]$ ./perftest -b localhost.localdomain --mechanism GSSAPI --username testuser --tx 1 --count 1 --summary --log-enable info+
2009-11-02 10:31:05 info Connecting to tcp:localhost.localdomain:5672
2009-11-02 10:31:05 info Installing security layer, SSF: 56
2009-11-02 10:31:05 warning Connection closed
Running the same test, but turning off clustering, authentication succeeds.
Alan has determined that the problem is due to the way the clustered broker constructs the codec chain. The chain is built without the codec for a secure connection.
The correct solution would implement a mechanism that allows more generic chaining of the codecs. It should be possible to allow codecs to be built that support both clustering and security/authentication.
In this case, the fix would secure the client/broker connection, and mirror the unencrypted data across the cluster.
Does this make sense? Opinions welcome.