qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Dispatch: Default value of authenticatePeer
Date Thu, 11 Aug 2016 20:02:27 GMT
FYI: I raised the issue DISPATCH-472 (
https://issues.apache.org/jira/browse/DISPATCH-472) to cover this.

On Thu, Aug 4, 2016 at 11:25 AM, 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
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message