You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Phil Harvey <ph...@philharveyonline.com> on 2012/09/24 17:14:48 UTC
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
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Phil Harvey <ph...@philharveyonline.com>.
Hi Alex,
Will it be possible to specify host name in the rule and restrict the
> access to the specified virtual host?
>
>
As you pointed out, this is not possible from the Firewall plugin. I am
trying to limit the scope of this work to be a "functionally neutral"
change, so I would prefer to not make this enhancement for now.
It is of course possible to specify an ACL file for each virtualhost if the
user requires fine-grained control.
> 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
>
>
That's an interesting idea. My personal preference is to keep the
user/group field separate from the from-network/from-hostnames fields. I
think the advantage of your proposal -- namely succinctness -- is
outweighed by the pitfalls (both from a developer and a user point of view)
of escaping the slash or @ characters that might occur in the user or group
name.
Phil
On 25 September 2012 14:19, Oleksandr Rudyy <or...@gmail.com> wrote:
> 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 <ph...@philharveyonline.com> 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 <ro...@gmail.com>
> 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 <ra...@gmail.com>
> 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
> >> > <ro...@gmail.com> 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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
> >> > >> > For additional commands, e-mail: dev-help@qpid.apache.org
> >> > >> >
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> > >> For additional commands, e-mail: dev-help@qpid.apache.org
> >> > >>
> >> > >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: dev-help@qpid.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Oleksandr Rudyy <or...@gmail.com>.
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 <ph...@philharveyonline.com> 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 <ro...@gmail.com> 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 <ra...@gmail.com> 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
>> > <ro...@gmail.com> 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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
>> > >> > For additional commands, e-mail: dev-help@qpid.apache.org
>> > >> >
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > >> For additional commands, e-mail: dev-help@qpid.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Phil Harvey <ph...@philharveyonline.com>.
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 <ro...@gmail.com> 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 <ra...@gmail.com> 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
> > <ro...@gmail.com> 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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
> > >> > For additional commands, e-mail: dev-help@qpid.apache.org
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > >> For additional commands, e-mail: dev-help@qpid.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
> >
>
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ra...@gmail.com> 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
> <ro...@gmail.com> 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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: dev-help@qpid.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: dev-help@qpid.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Rajith Attapattu <ra...@gmail.com>.
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
<ro...@gmail.com> 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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
>> > For additional commands, e-mail: dev-help@qpid.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ra...@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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: dev-help@qpid.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <cr...@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" <ph...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Java broker proposal: move firewall rules into ACL file
(QPID-4334)
Posted by Chuck Rolke <cr...@redhat.com>.
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" <ph...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org