activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arthur Naseef (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AMQ-3154) unable to implement custom broker-to-broker authorization
Date Thu, 17 Feb 2011 17:23:24 GMT

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

Arthur Naseef edited comment on AMQ-3154 at 2/17/11 5:22 PM:
-------------------------------------------------------------

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:
&nbsp;&nbsp;ON CONNECTION
&nbsp;&nbsp;&nbsp;&nbsp;IF client IS a broker
&nbsp;&nbsp;&nbsp;&nbsp;THEN
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DO check authentication
&nbsp;&nbsp;&nbsp;&nbsp;ELSE
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DO reject connection
&nbsp;&nbsp;&nbsp;&nbsp;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!

      was (Author: artnaseef):
    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

        

Mime
View raw message