qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Dispatch: Default value of authenticatePeer
Date Fri, 05 Aug 2016 18:39:14 GMT
On Thu, 2016-08-04 at 23:35 +0100, Gordon Sim wrote:
> On 04/08/16 21:49, Andrew Stitcher wrote:
> > 
> > Incidentally any connection that bypasses authentication will be
> > treated the same as if it connected using the ANONYMOUS mechanism
> > and
> > given user name "anonymous". I would expect that this should be
> > used in
> > any ACLs in force.
> The problem is that you might take steps to disable ANONYMOUS as a 
> mechanism, but not realise that there is a backdoor left open by
> default.

Agreed. It makes good sense to treat SASL bypass as equivalent to the
ANONYMOUS SASL mechanism at an application level.

However the idea of having SASL layer code turning off a transport
feature makes me a bit architecturally queasy.

I'd suggest changing the default to require_auth==True would be the
better direction.

Also bear in mind that if require-auth is true then ANONYMOUS SASL will
also not be allowed even if it is the negotiated mechanism. The proton
code will go through the SASL negotiation and then notice that there is
no authentication and close the connection.

It is necessary to do it this way because you could have a connection
with TLS authentication, but using SASL ANONYMOUS and the connection
would still be authenticated. Its more normal to use EXTERNAL in this
case, but AMQP does not require it and proton should cope with this

It is important to remember that authentication and encryption
responsibilities are shared between the SASL and TLS layers.


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

View raw message