[ 
https://issues.apache.org/jira/browse/QPID-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666165#action_12666165
 ] 

Marnie McCormack commented on QPID-1583:
----------------------------------------

The whitelist should not be in the virtual hosts file as I think it likely that 
these config details may be owned by different teams. It should also be 
possible to specify an IP address once in the config and apply it to a) all 
brokers on this server b) all vhs on this broker c) ultimately all brokers in 
this cluster etc.

Commons config will sort out the listening for updates out of the box, so no 
need to introduce anything new from that pov 
(http://commons.apache.org/configuration/userguide/howto_events.html)

> IP White/Black lists for virtual hosts
> --------------------------------------
>
>                 Key: QPID-1583
>                 URL: https://issues.apache.org/jira/browse/QPID-1583
>             Project: Qpid
>          Issue Type: New Feature
>          Components: Java Broker
>    Affects Versions: M5
>            Reporter: Aidan Skinner
>            Assignee: Aidan Skinner
>             Fix For: M5
>
>
> Having white/black lists for connecting to a virtual host would be useful.
> Questions:
> - need to provide an easy way for operate to maintain, secure & backup this 
> list
> - should consider what to do if there file/props etc for this are 
> corrupt/format wrong
> - if possible, the security filtering this provides should be part of a 
> potential chain of access REDUCING plugins so that this is easy to drop in 
> and teams can potentially write their own reducing filter class and use 
> abstraction to define in config for broker
> - needs to be at vhost level, and potentially at queue level ?
> ------------
> Explicit allow/deny lists of connection patterns on virtualhosts in 
> config.xml, existing ACL infrastructure for entities below that.
> Pattern would be one of:
> IP address
> CIDR mask
> regexp on hostname
> Changes would not be possible while broker was running, the file would need 
> to be editted and then the broker restarted. This avoids the necessity to 
> consider what happens to existing connections which would be excluded by a 
> new rule. Errors in configuration would prevent broker startup.
> Implementation wise, a new IPRestriction class would extend ACLPlugin which 
> listens for ConnectionOpen and checks against the list of rules.
> AMQProtocolSession needs to expose access to the underlying socket. 
> --- 
> We may need to reconsider allowing changes to the lists while the broker is 
> running. It would probably imply storing these outwith the main configuration 
> file and instead having something else, potentially a properties file, which 
> could be editted by the broker as it runs. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Reply via email to