[
https://issues.apache.org/jira/browse/AMQ-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995935#comment-12995935
]
Arthur Naseef commented on AMQ-3154:
------------------------------------
The JaasNetworkTest method should work - I'm just concerned about a short
timeout leading to incorrect results.
Trying to clarify - some of this may be a rehash.
Perhaps this description of the problem will help:
- Need connectors on a broker that can only be used by other, authenticated,
brokers
- Those connectors can not be used by regular clients - only authenticated
peer brokers
So, the high level desired flow would be:
ON CONNECTION
IF client IS a broker
THEN
DO check authentication
ELSE
DO reject connection
END IF
Securing addConnection() sounds like a good approach, but rejecting a
connection does not prevent the creation of network bridges in
TransportConnection's processBrokerInfo(). On the other hand, testing shows
that exceptions on addBroker() do not prevent the bridges and do not stop the
peer from continuing to create a connection. So, I believe both need to be
done.
These obervations are based on the 5.4.2 code; I do see that addBroker()'s
handling has changed on the trunk, so that's why it would be good to have a
JUnit that can confirm the results of an exception on addBroker() are
as-expected.
Checking getPeerBrokerInfos() is one place to check. Another is to look for
network bridges. I'll try that approach.
Thanks!
> 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
