Sorry about the late reply; I'm traveling. 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.
Would the acceptable fix have to plumb the new API through all bindings? -----Ursprüngliche Nachricht----- Von: Andrew Stitcher [mailto:astitc...@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%2fwww.o > asis-open.org%2fcommittees%2fdocument.php%3fdocument_id%3d50506%26&dat > a=01%7c01%7cclemensv%40microsoft.com%7c06d400131a5945f544bb08d2bac3ca0 > 2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AGNP6Xe0lSYS1oUOrXEao55 > 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
