qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: AW: AW: SASL negotiation w/ EXTERNAL
Date Wed, 16 Sep 2015 20:00:55 GMT
On Wed, 2015-09-16 at 16:34 +0000, Clemens Vasters wrote:
> ...
> The current behavior of Service Bus of offering up EXTERNAL in spite
> of not having gotten and verified a client credential at the TLS
> level not correct, and we've identified that as a bug on our side in
> the process of digging through this.
Interop testing of all kinds is pretty good at flushing out these sorts
of issues.

> Would the acceptable fix have to plumb the new API through all
> bindings?

By acceptable fix do you mean add pn_messenger_allow_sasl_mechs()? Or
something else?

The Proton SASL API has been designed to "just work" in as many cases
as possible, with only a few extra API hooks to configure it. I believe
that he underlying Proton engine API has all the necessary hooks and so
any new API binding should have them too.

The messenger API is special in that it insulates its use from the
engine to a large extent and doesn't really expose the transport (and
hence SASL) details. I had hoped that I wouldn't need to add SASL
functionality to the messenger API itself, but it seems that for
interop reasons such as this issue, it is necessary. So after adding
this new API any bindings of the messenger API will also get the new

I'm not sure if that answers your question, as I'm not 100% sure what
the question was.


> -----Urspr√ľngliche Nachricht-----
> Von: Andrew Stitcher [mailto:astitcher@redhat.com] 
> Gesendet: Freitag, 11. September 2015 18:12
> An: proton@qpid.apache.org
> Betreff: Re: AW: SASL negotiation w/ EXTERNAL
> On Wed, 2015-09-09 at 17:03 +0000, Clemens Vasters wrote:
> > ...
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fww
> > w.o
> > asis
> > -open.org%2fcommittees%2fdocument.php%3fdocument_id%3d50506%26&dat
> > a=01%7c01%7cclemensv%40microsoft.com%7c06d400131a5945f544bb08d2bac3
> > ca0
> > 2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AGNP6Xe0lSYS1oUOrXEa
> > o55
> > 1nsqmeP98BZpQpf0ggq8%3d
> > wg_abbrev=amqp
> I looked at this and I agree it does seem quite powerful.
> IUC you need an authenticated AMQP connection of some sort (ANON
> would
> work) to send the claims though.
> So I still don't understand why the server would be offering EXTERNAL
> seeing as it already knows that the client certificate isn't good
> enough to authenticate the connection.
> [Not a objection to adding the new messenger API, it just seems like
> the service bus behaviour is wrong to me]
> Andrew

View raw message