qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Scholz <ja...@scholz.cz>
Subject Re: Proposed SASL changes (API and functional)
Date Wed, 25 Feb 2015 09:27:08 GMT
Hi Andrew,

I'm definitely not a Proton expert, so please excuse me if I missed

But I find this part a bit dangerous:
"Classically in protocols where SASL was not optional the way to avoid
double authentication was to use the EXTERNAL SASL mechanism. With AMQP,
SASL is optional, so if SSL is used for client authentication the SASL
layer could be entirely omitted and so using EXTERNAL is not necessary."

I understand the idea and I would even agree that this is the proper way
how to do it in the long term. But I'm not sure whether all brokers support
this concept. For example, I'm not sure whether you can configure the Qpid
C++ broker in a way to accept AMQP 1.0 connections with SSL Client
Authentication without SASL EXTERNAL while at the same time accepting AMQP
0-10 connections only with SASL EXTERNAL. Therefore I would be afraid that
allowing SSL Client Authentication only without SASL could cause some
serious incompatibilities - I think both should be possible / supported.


On Tue, Feb 24, 2015 at 9:48 PM, Andrew Stitcher <astitcher@redhat.com>

> As many of you know I've been working on implementing a SASL AMQP
> protocol layer that does more than PLAIN and ANONYMOUS for proton-c.
> I'm currently in at a point where the work is reasonably functional
> (with some gaps)
> I've put together a fairly comprehensive account of this work on the
> Apache wiki: https://cwiki.apache.org/confluence/x/B5cWAw
> If you are at all interested please go and look at the proposal and
> comment on it there.
> You can see my actual code changes in my github proton repo:
> https://github.com/astitcher/qpid-proton/commits/sasl-work
> [This is my working branch, so not all the changes make a lot of sense,
> just pay attention to the tip of the branch]
> In a short while when people have had enough time to absorb the proposal
> and comment I will post a code review of the actual code changes. As
> there are substantial API changes I'd like to get this in for 0.9
> because we were intending to stabilise the API at this point.
> Thanks.
> Andrew

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