qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: Dispatch: Default value of authenticatePeer
Date Thu, 04 Aug 2016 14:21:10 GMT
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


Mime
View raw message