Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
MIME-Version: 1.0
In-Reply-To: <1720001197.23696583.1470320470812.JavaMail.zimbra@redhat.com>
References: <CAOhBXQ6+oJsnVnHPr7n9=uYqNz7xT+T3R7rBp=4XK0M+cj7QNg@mail.gmail.com>
 <CAFitrpToUSjZDW7=vYL=-8xC0hRHanax6iy1nyc4M6wZVKxdSA@mail.gmail.com>
 <c26b41d0-8993-ae3a-f326-ede1e28b11ed@redhat.com> <CAFitrpRFKVuJtb695aksgtHZXjfa8Gv+TuJ-BpMSrfuvJ3tJew@mail.gmail.com>
 <CAOhBXQ6dsJ5FCNjcg5RseG66-HX_U6YxWD-PDy6Dg0rtBuCKcQ@mail.gmail.com>
 <CAFitrpQ9P02xukrQj84FnmxMxx=3tT56tDJJp=0EHyR04FyTTw@mail.gmail.com> <1720001197.23696583.1470320470812.JavaMail.zimbra@redhat.com>
From: Robbie Gemmell <robbie.gemmell@gmail.com>
Date: Thu, 4 Aug 2016 16:11:20 +0100
Message-ID: <CAFitrpT-Oer5xWTOS0CB=YNLfqG6k3MRic4YVYrnbOe0S4NgJw@mail.gmail.com>
Subject: Re: Dispatch: Default value of authenticatePeer
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Thu, 04 Aug 2016 15:11:38 -0000

There are some cases where it is a useful combination so I'm not sure
a warning is the way to go. Making authenticatePeer default to yes if
a value isnt specified seems like a nice idea to me. Its specified as
no in the default config file thats shipped so behaviour there wouldnt
change, and having to specify it as no seems less likely to surprise
folks than the behaviour Jakub's example config gives.

Robbie

On 4 August 2016 at 15:21, Chuck Rolke <crolke@redhat.com> wrote:
> With the current behavior the router could issue a warning when SASL
> mechanisms are defined but authenticatePeer is absent or false.
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <robbie.gemmell@gmail.com>
>> To: users@qpid.apache.org
>> Sent: Thursday, August 4, 2016 6:06:34 AM
>> Subject: Re: Dispatch: Default value of authenticatePeer
>>
>> One could definitely argue that. I originally wanted to change, or
>> rather not introduce, the current underlying behaviour in Proton but I
>> agree that it could be handled nicer for Dispatch regardless.
>>
>> On 4 August 2016 at 10:25, Jakub Scholz <jakub@scholz.cz> wrote:
>> > One could argue that even if it works the same way in Proton, there might
>> > be different audience. From developer writing a Proton based server, I
>> > would expect more detailed knowledge about the Proton internals as well as
>> > AMQP internals. I would expect less knowledge from someone who is only
>> > configuring and running Dispatch.
>> >
>> > Even if we don't change the default value, we should at least improve the
>> > documentation. Right now there is not much about configuring the listeners
>> > in a "secure way". I will raise a JIRA and try to prepare something for the
>> > docu.
>> >
>> > On Wed, Aug 3, 2016 at 7:23 PM, Robbie Gemmell <robbie.gemmell@gmail.com>
>> > wrote:
>> >
>> >> On 3 August 2016 at 18:08, Gordon Sim <gsim@redhat.com> wrote:
>> >> > On 03/08/16 17:54, Robbie Gemmell wrote:
>> >> >>
>> >> >> On 3 August 2016 at 17:37, Jakub Scholz <jakub@scholz.cz> wrote:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> When I have listener configured like this:
>> >> >>>
>> >> >>> listener {
>> >> >>>     role: normal
>> >> >>>     host: 0.0.0.0
>> >> >>>     port: amqp
>> >> >>>     saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
>> >> >>>     linkCapacity: 1000
>> >> >>> }
>> >> >>>
>> >> >>> Is it really expected that it allows anonymous access? It seems that
>> >> >>> unless
>> >> >>> I add to the listener configuration also "authenticatePeer: yes", it
>> >> will
>> >> >>> always allow anonymous access to clients which don't trigger the SASL
>> >> >>> layer.
>> >> >>>
>> >> >>> This seems to me as something quite counter-intuitive and dangerous,
>> >> >>> because on a first look someone (like me for example :-o) might expect
>> >> >>> that
>> >> >>> this configuration allows only username/password authenticated access.
>> >> >>>
>> >> >>> Wouldn't it make more sense to have anonymous access disabled by
>> >> default?
>> >> >>> At least when SASL layer is configured for given listener? Or is it
>> >> just
>> >> >>> me
>> >> >>> who finds this confusing?
>> >> >>>
>> >> >>> Regards
>> >> >>> Jakub
>> >> >>
>> >> >>
>> >> >> From previous discussion (mainly around Proton where some of the
>> >> >> underlying behaviour originates) I believe it is actually expected
>> >> >> behaviour, but like you I don't think it is very intuitive, and would
>> >> >> again suggest we change it.
>> >> >
>> >> >
>> >> > I think this is different from proton's behaviour (and from qpidd's)
>> >> where
>> >> > the similar flags are false by default. (This is a distinct concern from
>> >> the
>> >> > default sasl mechanisms enabled).
>> >> >
>> >> >
>> >>
>> >> Without looking at any code to actually know for sure, my thinking
>> >> from previous discussion was that it stems from the proton-c transport
>> >> 'requireAuthentication' style config, which defaults false as you say
>> >> thus allowing either SASL or non-SASL connections by default, and so
>> >> by not setting the authenticatePeer setting in Dispatch config
>> >> proton's related transport config also remains false and continues to
>> >> allow the non-SASL connections, with the saslMechanisms config only
>> >> controlling which mechs any SASL connections can use.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> >> For additional commands, e-mail: users-help@qpid.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org