qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Multiple connections with ssl client auth does not work as expected
Date Tue, 22 Aug 2017 20:18:42 GMT
On 21/08/17 21:46, Chris Richardson wrote:
> Hi,
> 
> I've encountered an issue with the C++ broker (1.36) where it appears
> that multiple connections within the same process using SSL client
> auth do not use the "ssl-cert-name" property provided when the
> connection instance is created. Rather, it appears the second
> connection will use auth details of the first connection.
> 
> Is this expected behaviour?
> 
> Setup to show this happening is rather involved so I've created a jira
> issue with some attached material to demonstrate the problem:
> https://issues.apache.org/jira/browse/QPID-7894.

I don't think I can reproduce your issue. I downloaded your reproducer 
and with a couple of minor modifications[1] ran it and it showed no deny 
logs.

The broker log has the following:

> 2017-08-22 21:11:23 [Security] debug ACL: Lookup for id:user1@QPID action:access objectType:queue
name:user1 with params { durable=false autodelete=false exclusive=false alternate= policytype=
maxqueuesize=0 max
> queuecount=0 }
> 2017-08-22 21:11:23 [Security] debug ACL: checking rule [rule 2 ruleMode = allow props{
name=${user} }]
> 2017-08-22 21:11:23 [Security] debug ACL: lookup name 'user1' matched with rule name
'${user}'
> 2017-08-22 21:11:23 [Security] debug ACL: Successful match, the decision is:allow
> 2017-08-22 21:11:23 [Security] debug ACL: Lookup for id:user1@QPID action:consume objectType:queue
name:user1 with params { }
> 2017-08-22 21:11:23 [Security] debug ACL: checking rule [rule 3 ruleMode = allow props{
name=${user} }]
> 2017-08-22 21:11:23 [Security] debug ACL: lookup name 'user1' matched with rule name
'${user}'
> 2017-08-22 21:11:23 [Security] debug ACL: Successful match, the decision is:allow
> 2017-08-22 21:11:23 [Security] debug ACL: Lookup for id:user2@QPID action:access objectType:queue
name:user2 with params { durable=false autodelete=false exclusive=false alternate= policytype=
maxqueuesize=0 max
> queuecount=0 }
> 2017-08-22 21:11:23 [Security] debug ACL: checking rule [rule 2 ruleMode = allow props{
name=${user} }]
> 2017-08-22 21:11:23 [Security] debug ACL: lookup name 'user2' matched with rule name
'${user}'
> 2017-08-22 21:11:23 [Security] debug ACL: Successful match, the decision is:allow
> 2017-08-22 21:11:23 [Security] debug ACL: Lookup for id:user2@QPID action:consume objectType:queue
name:user2 with params { }
> 2017-08-22 21:11:23 [Security] debug ACL: checking rule [rule 3 ruleMode = allow props{
name=${user} }]
> 2017-08-22 21:11:23 [Security] debug ACL: lookup name 'user2' matched with rule name
'${user}'
> 2017-08-22 21:11:23 [Security] debug ACL: Successful match, the decision is:allow
> 2017-08-22 21:11:23 [Security] trace ACL ConnectionCounter closed: qpid.127.0.0.1:5671-127.0.0.1:56482,
userId:user1@QPID
> 2017-08-22 21:11:23 [Security] trace ACL ConnectionCounter closed: qpid.127.0.0.1:5671-127.0.0.1:56484,
userId:user2@QPID

Which looks like the connections were correctly identified.

I'm using latest master for qpid-cpp and nss-devel-3.31.0-1.1.fc25.x86_64.

Am I doing something wrong, or do our setups differ?

[1] The changes I made were (a) to not use the qpid-cpp based 
qpid-config to create the two queues and (b) I built the test client 
without your cmake file, both just for convenience on my part.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message