On 3 August 2016 at 18:08, Gordon Sim <g...@redhat.com> wrote:
> On 03/08/16 17:54, Robbie Gemmell wrote:
>>
>> On 3 August 2016 at 17:37, Jakub Scholz <ja...@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-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
