I'm not entirely clear from your description how you've been configuring SASL. Usually the CMake configure phase will choose the SASL configuration depending on the libraries it detects on the system you are running on. If you only want to use PLAIN and EXTERNAL (over TLS presumably) then you don't need Cyrus SASL and the default SASL provider will be sufficient for your needs.
If you are using Cyrus SASL on some Linux distributions you may need to have the package containing the PLAIN mechanism installed too otherwise that mechanism will not be available for Cyrus SASL to use. Hope that helps. Andrew On Tue, Jun 11, 2024 at 5:37 AM Andrew North <andrew.no...@campbellsci.co.uk> wrote: > Just to update on this, I have included both sources (cyrus_sasl.c and > cyrus_stub.c) and it works as expected. > > > > Cheers > > > > > *From:* Andrew North > *Sent:* Monday, June 10, 2024 3:57 PM > *To:* users@qpid.apache.org > *Subject:* Is SASL_SSL enforced with qpid-proton when CyrusSASL > dependency is used > > > > Hi, > > > > I’ve been using qpid-proton 0.39 C/C++, I have been testing with an > extended version of the samples. > > I’m sending secure messages and authenticating connections with SSL > certificates I have generated manually connecting to a RabbitMQ broker. > > I’ve validated the certificates and connections using openssl on the > terminal and using qpid-proton samples. > > I’m using both OpenSSL and CyrusSASL dependencies. > > > > I have a “bug” perhaps in configuration of my client, where when I enable > the dependency for cyrus-sasl.c over the cyrus-stub.c, I am no longer > able to authenticate using “PLAIN”, and my default connection is forcing > “EXTERNAL” SASL mechanism even if explicitly set it to false in connection > options. > > > > Below are some snippets from my tests: > > This is my dummy_client > > “”” > > class dummy_client : public proton::messaging_handler { > > public: > > void on_container_start(proton::container& c) override { > > proton::connection_options client_opts; > > client_opts.handler(*this); > > > > if(this->_use_auth){ > > client_opts.user(this->_user); > > client_opts.password(this->_password); > > } > > > > client_opts.sasl_enabled(false); > > > > if(this->_use_ssl) { > > std::string client_cert = this->_cert_dir + "client-cert.pem"; > > std::string client_key = this->_cert_dir + "client-key.pem"; > > std::string client_pw = "password"; > > std::string client_ca = this->_cert_dir + "ca-cert.pem"; > > proton::ssl_certificate ssl_cert(client_cert, client_key, > client_pw); > > proton::ssl_client_options ssl_client_opts(ssl_cert, client_ca, > proton::ssl::VERIFY_PEER); > > if(this->_use_sasl){ > > client_opts.sasl_enabled(true); > > > client_opts.ssl_client_options(ssl_client_opts).sasl_allowed_mechs(this->_sasl_mech); > > } else { > > client_opts.ssl_client_options(ssl_client_opts); > > } > > } > > > > if(this->_sasl_mech == "INSECURE") { > > client_opts.sasl_allow_insecure_mechs(true); > > } > > > > proton::sender s = c.open_sender(this->_url + "/" + this->_address, > client_opts); > > } > > > > void on_sendable(proton::sender& s) override { > > proton::message m; > > m.body("Hello World!"); > > s.send(m); > > s.close(); > > } > > } > > “”” > > > > Simplified test logic: > > “”” > > { > > dummy_client client; > > proton::container container(client); > > local_thread = std::jthread([&](){ container.run(); }); > > std::this_thread::sleep_for(std::chrono::microseconds(wait_sec*1000000)); > > if (local_thread.joinable()) { > > container.stop(); > > local_thread.join(); > > } > > } > > “”” > > > > I have multiple tests with the following configurations: > > - _url=target_ip:{5672,5671} > - _*address=test*_NN > - _*use*_auth={true,false} > - _*user={guest,new*_user} > - _password={guest,password} > - _*use*_ssl={true,false} > - _*use_sasl={true,false}* > - *_sasl_mech={“INSECURE”,”PLAIN”,”EXTERNAL”}* > > > > I have run the tests in 4 different scenarios, below are the results: > > - Using one of these two dependencies {cyrus_stub.c, cyrus_sasl.c} > - RabbitMQ – SASL_SSL authentication {on, off} > > > > port > > use_auth > > user > > password > > use_ssl > > use_sasl > > sasl_mech > > result w/plugin > w/cyrus_stub.c > > result wo/plugin > w/cyrus_stub.c > > result w/plugin > > w/cyrus_sasl.c > > result wo/plugin > w/cyrus_sasl.c > > 5672 > > - > > - > > - > > - > > - > > - > > PASS > > PASS > > PASS > > PASS > > 5672 > > X > > guest > > guest > > - > > - > > - > > PASS > > PASS > > FAIL - SASL error (-4) > > FAIL - SASL error (-4) > > 5672 > > X > > new_user > > password > > - > > - > > - > > PASS > > PASS > > FAIL - SASL error (-4) > > FAIL - SASL error (-4) > > 5671 > > - > > - > > - > > X > > - > > "INSECURE" > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > X > > guest > > guest > > X > > - > > "INSECURE" > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > X > > new_user > > password > > X > > - > > "INSECURE" > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > - > > - > > - > > X > > - > > - > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > X > > guest > > guest > > X > > - > > - > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > X > > new_user > > password > > X > > - > > - > > ERROR > > PASS > > PASS > > FAIL - SASL error (-4) > > 5671 > > X > > guest > > guest > > X > > X > > "PLAIN" > > PASS > > PASS > > FAIL - SASL error (-4) > > FAIL - SASL error (-4) > > 5671 > > - > > - > > - > > X > > X > > "PLAIN" > > FAIL - auth mech=none > > FAIL - auth mech=none > > FAIL - SASL error (-4) > > FAIL - SASL error (-4) > > 5671 > > X > > guest > > guest > > X > > X > > "EXTERNAL" > > PASS > > FAIL - auth mech=none > > PASS > > FAIL - auth > > 5671 > > - > > - > > - > > X > > X > > "EXTERNAL" > > PASS > > FAIL - auth mech=none > > PASS > > FAIL - auth > > > > Summary of results using cyrus_stub.c: > > - Can always connect and send unsecure messages with no configuration > set (assuming this means “ANONYMOUS”) > - RabbitMQ NOT Using SASL_SSL: > - Can connect and send unsecure messages via port 5672, even with > user credentials > - Can connect and send secure messages via port 5671, even with > user credentials > - Can authenticate using “PLAIN” SASL > - Fails to authenticate using “EXTERNAL” assumed to be SASL_SSL > authentication > - RabbitMQ Using SASL_SSL: > - Can connect and send unsecure messages via port 5672, even with > user credentials > - Can’t connect and send secure messages via port 5671 > - Can authenticate using “PLAIN” SASL, and send secure messages via > port 5671 > - Can authenticate using “EXTERNAL”, assumed to be SASL_SSL > authentication and send secure messages via port 5671 > > > > Summary of results using cyrus_sasl.c: > > - Can always connect and send unsecure messages with no configuration > set (assuming this means “ANONYMOUS”) > - RabbitMQ NOT Using SASL_SSL: > - Can’t connect or send unsecure/secure message via ports > 5672/5671, with or without user credentials > - Can’t authenticate using “PLAIN” SASL > - Fails to authenticate using “EXTERNAL” assumed to be SASL_SSL > authentication > - Always assumes SASL is using “EXTERNAL” mech when sasl is > explicitly disabled using “client_opts.sasl_enabled(false);” > - RabbitMQ Using SASL_SSL: > - Can’t connect and send unsecure messages via port 5672, even with > user credentials > - Can connect and send secure messages via port 5671 – but > transport assumes use of “EXTERNAL” mech. > - Can’t authenticate using “PLAIN” SASL > - Can authenticate using “EXTERNAL”, assumed to be SASL_SSL > authentication and send secure messages via port 5671 > > > > Let me know if you can see the formatted results as a table, I also have > the following questions: > > - Are we forced to use SASL authentication if we use dependency > cyrus_sasl.c as opposed to cyrus_stub.c? > - Is there a configuration I am doing by mistake? > - Can a client be configured to open a container with “PLAIN” > authentication, and a second container be opened with “EXTERNAL” or “NONE” > depending on other log > > > > If you have any suggestions or further clarity regarding above, that would > be great thanks. I will continue to experiment with what I have. > > > > Kind Regards, > > Andrew >