| Summary: | Different authentication behavior of python client when EXTERNAL mechanisms is used | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Petra Svobodová <psvobodo> |
| Component: | python-qpid | Assignee: | messaging-bugs <messaging-bugs> |
| Status: | NEW --- | QA Contact: | Messaging QE <messaging-qe-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | Development | CC: | iboverma, jross, zkraus |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Description of problem: Python client needs to have given right username, what must pass with username from the client certificate, if EXTERNAL mechanisms is used by broker. I am not sure, if it is an issue, however this behavior is different from C++ and Perl clients, what are able to authenticate the client only via the certificate. Version-Release number of selected component (if applicable): # rpm -qa | grep qpid qpid-java-common-0.23-4.el6.noarch qpid-cpp-client-devel-0.22-29.el6.i686 rh-qpid-cpp-tests-0.22-29.el6.i686 qpid-java-amqp-0-10-client-jms-0.23-4.el6.noarch qpid-qmf-0.22-24.el6.i686 qpid-cpp-server-rdma-0.22-29.el6.i686 qpid-java-example-0.23-4.el6.noarch qpid-snmpd-1.0.0-14.el6.i686 qpid-cpp-client-0.22-29.el6.i686 python-qpid-qmf-0.22-24.el6.i686 qpid-cpp-server-devel-0.22-29.el6.i686 ruby-qpid-qmf-0.22-24.el6.i686 qpid-cpp-server-xml-0.22-29.el6.i686 qpid-java-client-0.23-4.el6.noarch qpid-jca-0.22-1.el6.noarch qpid-proton-c-devel-0.5-9.el6.i686 qpid-cpp-client-devel-docs-0.22-29.el6.noarch qpid-cpp-client-rdma-0.22-29.el6.i686 qpid-cpp-debuginfo-0.22-16.el6.i686 qpid-tools-0.22-7.el6.noarch qpid-cpp-server-store-0.22-29.el6.i686 perl-qpid-0.22-7.el6.i686 qpid-jca-xarecovery-0.22-1.el6.noarch qpid-proton-c-0.5-9.el6.i686 qpid-cpp-server-0.22-29.el6.i686 qpid-cpp-server-ssl-0.22-29.el6.i686 python-qpid-0.22-8.el6.noarch qpid-cpp-client-ssl-0.22-29.el6.i686 qpid-cpp-server-ha-0.22-29.el6.i686 How reproducible: 100% Steps to Reproduce: 1. Generate certification authority's and client's certificates in ".pem" formats. 2. Run a broker over SSL. 3. Try to connect the broker via EXTERNAL mechanism with connection options: "{ ssl_certfile : <path_to_the_client_certificate>, ssl_skip_hostname_check : 'false', sasl_mechanisms : 'EXTERNAL', ssl_trustfile : <path_to_the_CAroot_certificate>, transport : 'ssl' }" Actual results: The client cannot connect the broker, authentication fails. Expected results: The authentication should be successful as if another client (C++ or Perl) is used and the connection should be created. Additional info: Broker's configuration: ssl-require-client-authentication=yes data-dir=/var/lib/qpidd log-to-file=/var/lib/qpidd/qpidd.log ssl-cert-name=server auth=yes acl-file=/etc/qpid/qpidd.acl log-enable=info+ ssl-cert-password-file=<path_to_the_password_file> port=5672 ssl-port=5671 ssl-cert-db=<path_to_the_certdb>