Hi Phil, Existing firewall plugin denies/allows access to broker from network/host regardless virtual host. The suggested syntax implies that you can denies/allows access to the broker virtual hosts instead. Will it be possible to specify host name in the rule and restrict the access to the specified virtual host?
Another question I have about adding predicates "from-network" and "from-hostname". Why we cannot provide the network or host name pattern as part of user/group name? For example, using the following constructions ACL ALLOW all/123.456.789/24 ACCESS VIRTUALHOST ACL DENY-LOG my-user-group/.*\.uat.mycompany\.com ACCESS VIRTUALHOST It looks like that existing ACL syntax allows to specify the user domain after character '/'. I would prefer to use '@' for this but it seems this character is reserved to specify the user realm. Alex On 25 September 2012 10:07, Phil Harvey <[email protected]> wrote: > Thanks for the feedback guys. > > Responding to Chuck's questions: > >> Your proposed syntax is basically OK. The C++ broker supports IPv4, >> IPv6, and RDMA. Could you specify the "--from-network xxxx" property >> more fully? > > As suggested by Robbie, the from-network and from-hostname properties will > retain the semantics of the similarly-named properties in the existing > firewall plugin (https://cwiki.apache.org/qpid/firewall-configuration.html), > such that this task is a "functionally neutral" refactoring. I think any > functional enhancements that arise (eg to match the C++ broker's firewall > support) should be done under a separate JIRA. > > >> Do you think this can make it in the next release? > > Yes, I expect to submit a patch in the next few days. > > > Unless there are any further objections I'm going to proceed with this > JIRA. > > Phil > > > On 25 September 2012 01:52, Robbie Gemmell <[email protected]> wrote: > >> Where the Java broker is concerned it wasnt moved in the timeframe of that >> mail thread simply because the ACL system in use at the time was limited >> and in need of removal more than anything else (which happened some time >> ago), so it didnt make sense to combine them at the time and it just hasn't >> happened since it did become worthwhile. Now there are new reasons it would >> be useful to combine them, to the extent it makes enough sense for us to >> combine the functionality now rather than later. >> >> I cant really say I recall any other discussions on this subject except the >> other postings on JIRA and/or the user list requesting the functionality it >> would offer. >> >> Robbie >> >> On 25 September 2012 01:19, Rajith Attapattu <[email protected]> wrote: >> >> > I'm not really against the change proposed by Philip. >> > But wanted to highlight the history around this area, in case anybody >> > remembers the reasons behind abandoning the previous effort. >> > It's always best to make a decision after considering all aspects. >> > I hope somebody still remembers why this didn't take place. >> > >> > Rajith >> > >> > On Mon, Sep 24, 2012 at 8:05 PM, Robbie Gemmell >> > <[email protected]> wrote: >> > > 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 <[email protected]> >> 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 <[email protected]> >> 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" <[email protected]> >> > >> >> To: [email protected] >> > >> >> 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: [email protected] >> > >> > For additional commands, e-mail: [email protected] >> > >> > >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: [email protected] >> > >> For additional commands, e-mail: [email protected] >> > >> >> > >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
