git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1496466 13f79535-47bb-0310-9956-ffa450edef68

Catch-up shadow connections were not being authenticated which caused two problems:
- new brokers failed to join the cluster if there was an authenticated session.
- possible security loophole that would allow an intruder to gain access to a catch-up broker.

All external connections are now fully authenticated, which solves both problems.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1352992 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1295730 13f79535-47bb-0310-9956-ffa450edef68

Changes missed from previous commit.

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1182514 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1182212 13f79535-47bb-0310-9956-ffa450edef68

provided by the transport layer when starting SASL.
This allows the SASL mechanism EXTERNAL to be satisfied with 
SSL transport security.
The test, sasl_fed_ex, uses this SASL/SSL security on a 
federated link between two brokers.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1050162 13f79535-47bb-0310-9956-ffa450edef68

-------------------------------------------------------------

1. Brokers already knew how to handle the server side of SASLized
   links, but not the client side.  So we promoted the client-side
   SASL code from the client library to the common library so that
   the broker could also use it.  This affected SaslFactory.{h,cpp}
   and Sasl.h
   TODO -- can the server-side and client-side code be unified here?

2. Some of the SASL verbs in broker/ConnectionHandler.cpp are
   expanded: start, secure, tune.

3. broker/SecureConnection is altered to get the client-broker and
   the server-broker to agree on when the security layer should be
   inserted.

4. the python tool qpid-route is modified so that, in the "route add"
   command, you can specify the security mechanism for SASL to use.
   TODO -- should we also pass in {min,max}SSF ?

5. Changes in broker/LinkRegistry to allow the information input by
   qpid-route to be passed up to where it is needed.

6. A bash script test run by "make check" that creates a SASLized
   federation link and sends some messages down it.
   TODO - write a python unit test instead of a bash script.  I
          think I uncovered a bug in the python code when I tried.

7. NOTE - testing for this feature does not work with versions of
   SASL earlier than 2.1.22, becuase I can't tell SASL to use a
   SASL database file in a nonstandard location.  The test is
   disabled for earlier versions.




git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@1024541 13f79535-47bb-0310-9956-ffa450edef68

The connection negotiation phase up to the "open" or "open-ok" frame
establishes whether/what encryption to use for the rest of the
connection.

With this patch a cluster broker completes the initial negotiation
with its local clients and only then begins multicasting to other
brokers. The local broker decrypts if necessary and multicasts in the
clear.

This replaces a problematic locking scheme that was formerly in place
which caused deadlocks.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@952692 13f79535-47bb-0310-9956-ffa450edef68

- was using "none" not empty string for no ID.
- was multicasting secure id for update and shadow connections.


git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@948967 13f79535-47bb-0310-9956-ffa450edef68

-----------------------------------

* initial observation of a problem was a 2% failure rate in perftests
  of 20,000 messages against a cluster with security enabled.
  Problem was occasional receit of encrypted frames before the
  security codec had been enabled.  This is fixed with locking in
  cluster code (no new locks in broker code) and a callback that is
  fired by broker::ConnectionHandler::Handler to tell the cluster
  code when the opening handshake has finished.
  This was never a problem in the non-clustered broker before because
  everything happened in a single thread.

* the brokers that "shadow" the connection must not have null
  authenticators rather than real ones, so that they go through all
  the motions but don't do anythig.  Only the directly-connected
  broker can perform the security handshake.

* once the directly-connected broker receives the real user ID
  from its callback, it mcasts that ID to all other brokers.
  Otherwise the shadowing brokers will al think that the user ID
  is "anonymous".
  Check this by doing a substantial perftest, and using
      qpid-stat -c localhost:PORT
  to confirm that the brokers all have the same userID for the
  same connection.

* the user ID, negotiated during the Sasl security startup, is
   communicated from the directly connected broker to all other
   cluster brokers.

* If security is *not* being used, then this code should *not* tell
  the brokers anything about the userID -- or it will step on the value
  that is being set by other code pathways.

* test program at cpp/src/tests/cluster_authentication_soak is not yet
  fully automated -- run it with something like
  "sudo ./cluster_authentication_soak 500"



git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk/qpid@944158 13f79535-47bb-0310-9956-ffa450edef68