The previous thread in [1] is of little relevance now as none of the ACL code under discussion there exists anymore. It is easy enough to argue that such restrictions would are best served by a real firewall, but there are reasons it still proves useful functionality for the broker to have and we have users we want to keep supporting the functionality for, even if we are changing the config (which doesnt particularly concern me, we are slowly moving towards an end state with config on the Java broker that will change config for almost everything..making this change now will just reduce the amount of future change slightly). Ultimately the functionality already exists, simplistically this is just going to be tweaking where the implementation lives and its config, though in the end it may actually add functionality too as a side effect (e.g. user specific network restriction, which I dont think is currently supported on the Java side).
The docs for the existing xml config for the Java broker effort lives at https://cwiki.apache.org/qpid/firewall-configuration.html and details its current hostname wildcarding and CIDR network matching. Robbie On 24 September 2012 21:23, Rajith Attapattu <rajit...@gmail.com> wrote: > The last time this came up for discussion there was some push back on the > list. > This was proposed here [1] due to some requests from the users and > there was even a patch for the c++ broker attached here [2] > However this didn't go through due to some discussion that happened on the > list. > Unfortunately I can't seem to find a reference to this on the mailing > list archives. > > Does anybody recall the reasons ? > > I vaguely remember that one of the reasons was that this could be > handled more effectively with a firewall than ACL. > > [1] > http://apache-qpid-developers.2158895.n2.nabble.com/IP-white-lists-for-brokers-td4127195.html > [2] https://issues.apache.org/jira/browse/QPID-2305 > > On Mon, Sep 24, 2012 at 3:33 PM, Chuck Rolke <cro...@redhat.com> wrote: > > I think the proposal makes sense and I'd like to see it common to all > brokers. > > > > To date the C++ broker ACL code has used only literal text strings for > host names as defined by the connection agent. Resolving network names > and/or subnets adds new code. > > > > Your proposed syntax is basically OK. The C++ broker supports IPv4, > IPv6, and RDMA. Could you specify the "--from-network xxxx" property more > fully? > > > > Do you think this can make it in the next release? > > > > -Chuck > > > > ----- Original Message ----- > >> From: "Phil Harvey" <p...@philharveyonline.com> > >> To: dev@qpid.apache.org > >> Sent: Monday, September 24, 2012 11:14:48 AM > >> Subject: Java broker proposal: move firewall rules into ACL file > (QPID-4334) > >> > >> I'm working on https://issues.apache.org/jira/browse/QPID-4334 > >> ("[Java > >> broker] move the Firewall functionality into the ACL plugin") and > >> want to > >> gather opinions on the desired behaviour. > >> > >> My main questions are: > >> - Are we happy to make this change to the Java Broker? > >> - If so, what is the nicest ACL syntax for firewall rules? > >> > >> The motivation for this work is to: > >> > >> (1) rationalise our set of plugins, thus making the implementation of > >> QPID-4335 ("[java broker] replace current plugin system with a > >> simplified > >> system") easier; > >> (2) make life simpler for our users. > >> > >> I expect the second point will be more contentious, hence this email. > >> > >> Putting myself in the user's shoes, I believe it makes sense for > >> access > >> control and firewall configuration to be done in one place, using > >> rules > >> such as: > >> > >> ACL ALLOW all ACCESS VIRTUALHOST FROM-NETWORK="123.456.789/24" > >> ACL DENY-LOG all ACCESS VIRTUALHOST > >> FROM-HOSTNAME=".*\.uat.mycompany\.com" > >> > >> I therefore propose to enhance the "ACCESS VIRTUALHOST" ACL rule to > >> support > >> the same network and hostname predicates that are currently supported > >> by > >> the firewall Java broker plugin. This will make the firewall plugin > >> redundant, so it will be deleted. > >> > >> The objections I'm anticipating are: > >> > >> - This will break require users to modify their config when they > >> upgrade. > >> I think this minor inconvenience is outweighed by the motivations > >> stated > >> above. > >> > >> - This will cause the Java and C++ ACL syntax to diverge further. I > >> don't > >> know if this is a showstopper. I understand that this enhancement > >> was > >> previously discussed for the C++ broker, and I'd be particularly > >> interested > >> to hear current views on this from the C++ folks. > >> > >> Let me know what you think. > >> > >> Thanks > >> Phil > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > > For additional commands, e-mail: dev-h...@qpid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
