Bug 1039109 - Different authentication behavior of python client when EXTERNAL mechanisms is used
Summary: Different authentication behavior of python client when EXTERNAL mechanisms i...
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid
Version: Development
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: messaging-bugs
QA Contact: Messaging QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-06 16:36 UTC by Petra Svobodová
Modified: 2020-11-04 22:29 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 895539 0 low NEW Client's identity shall be taken from the SSL certificate when EXTERNAL sasl mechanism is used 2021-02-22 00:41:40 UTC

Internal Links: 895539

Description Petra Svobodová 2013-12-06 16:36:13 UTC
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>


Note You need to log in before you can comment on or make changes to this bug.