Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Thu, 17 Feb 2011 09:43:24 +0000 (UTC)
From: "Gary Tully (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <1355199961.2266.1297935804422.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <12393369.174281295912563396.JavaMail.jira@thor>
Subject: [jira] Commented: (AMQ-3154) unable to implement custom
 broker-to-broker authorization
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQ-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995735#comment-12995735 ] 

Gary Tully commented on AMQ-3154:
---------------------------------

Go high level with your junit test, having more than one broker is not a problem. Maybe org.apache.activemq.security.JaasNetworkTest can provide some inspiration.

The BrokerInfo command is the only difference between a client and a broker connection.
To see if a broker connection is complete, org.apache.activemq.broker.region.RegionBroker#getPeerBrokerInfos can give you some high level view.
Not sure if this answers your questions but I hope it helps :-)

> 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: pre_add_broker.patch
>
>
> 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