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 API. I'm not sure if that answers your question, as I'm not 100% sure what the question was. Andrew > > -----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%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 >
