[
https://issues.apache.org/jira/browse/AMQ-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arthur Naseef updated AMQ-3154:
-------------------------------
Attachment: trunk2011-02-17_result.txt
Full output running against 5.5 trunk snapshot checked out today, 17 Feb 2011;
rev: 1071750.
Something is notably different. The test is getting 4 persistence adapters
configured, according to the log output, and one is a KahaDB even though both
brokers have been set to be non-persistent.
> unable to implement custom broker-to-broker authorization
> ---------------------------------------------------------
>
> Key: AMQ-3154
> URL: https://issues.apache.org/jira/browse/AMQ-3154
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Arthur Naseef
> Attachments: AMQ3154Test.java, pre_add_broker.patch,
> trunk2011-02-17_result.txt
>
>
> Ran into the following issues preventing a custom Broker-To-Broker
> authentication implementation:
> - BrokerFilter's addBroker() can not be used to secure a connection:
> - for duplex connections, it is never called on the initial conneciton
> - even if addBroker() throws an exception, it does not deny access (it
> does not close the connection nor prevent other functioning)
> - addBroker() does not have direct access to the ConnectionContext, nor
> any other means for the BrokerFilter to access SSL certificates on the SSL
> transport
> - BrokerFilter's addConnection() can not be used to secure a connection:
> - there is no way to distinguish broker connections from clients
> Other approaches were considered, but lead to dead-ends.
> It seems the optimal solution would use the existing addBroker() method.
> A patch will be provided that adds a new method specifically for securing
> Broker-To-Broker connections.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
