Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The messaging broker and clients need to be able to use SSL client certificates for authentication in such a way that it integrates properly with the broker ACLs (i.e. the identity associated with a connection/message must be derived from the DN of the client certificate).
I just took a quick inspection of the code. It looks like sasl_getprop() of the ssl connection struct ought to reveal the right bits. Am I missing something? I'll work out how to set up some brokers with ssl and try it.
Hello, I should be testing this at some point. What is the status of SASL EXTERNAL support and where can I find related documentation? Thanks, Ján (QE)
I have pushed a backport of this feature to the 1.2 release repo.
This feature works by setting the authorisation id used in process ACLs based on the identity of the clients certificate. It is thus only available on client authenticated SSL connections. This requires that the --ssl-require-client-authentication option is selected for qpidd. The authorisation id is taken to be the common name (CN) of the certificate, with any domain components (DC) defining the realm. E.g. Subject "CN=bob,O=acme,ST=Mass,C=US,DC=example,DC=com" would result in an authorisation id of bob, as would "CN=bob,O=acme,ST=Mass,C=US". "CN=bob,O=acme,ST=Mass,C=US" will result in an authorisation id of bob in the default realm. By default a client can negotiate another mechanism even on client authenticated SSL connections. To prevent this the --ssl-sasl-no-dict option can be specified. This prevents any mechanism being used that is vulnerable to a dictionary attack, and in effect reduces the options to EXTERNAL.
Note that until inter-broker links support full SASL negotiation (see bug 500430), the --ssl-sal-no-dict option would prevent use of SSL on inter broker links.
Created attachment 396046 [details] verification script, version 1 I am not sure if I am doing something wrong, but when I run qpidd and perftest with following arguments, I am always getting the message at the bottom (one line produced by perftest): export QPID_NO_MODULE_DIR=1 export QPID_LOAD_MODULE=`rpm -ql qpid-cpp-server-ssl | grep ssl.so` export QPID_SSL_CERT_DB=$PWD export QPID_SSL_CERT_PASSWORD_FILE=$PWD/pwdfile.txt qpidd -d --ssl-require-client-authentication \ --ssl-cert-name "ourServer" --auth yes export QPID_LOAD_MODULE=`rpm -ql qpid-cpp-client-ssl | grep sslconnector.so` export QPID_SSL_CERT_NAME="ourClient" perftest --count 10 --port 5671 -P ssl -b localhost --summary error IO worker thread exiting with unhandled exception: Success (qpid/sys/ssl/SslIo.cpp:386)
Excuse me, the bug is still ASSIGNED so maybe it's not supposed to work yet. Let me know please. By the way, I am testing on RHEL5 x86_64 candidate packages qpid-cpp-server-ssl-0.7.908272-1.el5
Low priority bug regarding the "unhandled exception" message created: https://bugzilla.redhat.com/show_bug.cgi?id=568657
Committed to trunk as r919487
Re-checked also on qpid-cpp-server-ssl-0.7.946106-1.el5, works.
Created attachment 416695 [details] verification script, v2
Created attachment 422113 [details] verification script, v3
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.+Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using SSL client certificates for authentication.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0773.html