Hi Clebert, As a little extra context for readers...with AMQP 1.0, if the client wishes to use SASL security it first establishes a SASL layer beginning with the AMQP%d3.1.0.0 header, and then if successfull proceed to establish the 'regular' AMQP connection over it beginning with the AMQP%d0.1.0.0 header. Details/diagrams at: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-security-v1.0-os.html#section-sasl
As you know, calling the sasl() method on the Proton transport will make it add the sasl layer and expect the relevant header for initial input, and also emit it when sending its initial output. You are thus concerned with how to know whether you should call the sasl() method. Currently you are correct that with proton-j you would have to sniff the traffic in order to support accepting both sasl layered connections and bare connections without sasl. The alternative is that you would always call sasl() and simply be unable to accept connections that skip the sasl layer, and if wishing to support unauthenticated connections for explicit no-auth scenarios doing so by either using the ANONYMOUS mechanism or simply accepting any credentials supplied via others. Ted added support to proton-c in 0.8 for a server to be able to add the transport sasl layer but also be able to identify the client skipped the sasl layer and then optionally allow it to do so by replying with the AMQP%d0.1.0.0 header. I stubbed the API for this in proton-j to get the test suite back running at all, but the functionality has yet to actually be implemented: https://issues.apache.org/jira/browse/PROTON-642 https://issues.apache.org/jira/browse/PROTON-655 I think the JMS clients currently expect the server to offer the SASL layer, and will negotiate the ANONYMOUS mechanism if that is all the server offers. I dont believe either client would currently handle the server replying with the bare connection header in response to them sending the sasl header, and I don't believe the new client yet supports skipping sending the SASL header but it looks like the old one might if provided with a null username. Robbie On 14 October 2014 19:20, Clebert Suconic <[email protected]> wrote: > qpid JMS clients currently expect to send anonymous connection in the > following way: > > > - if the first frame has the SASL byte 3 (I'm not reading the spec now.. > I'm not sure the correct term), the server is supposed to initialize SASL > on the connection, transport... etc > In other terms, if the following frame arrives, we need to create SASL > with the proper capabilities: > > 414D5150 -->03<-- 010000 > > * just as a reference for general audience, 414D5150 == AMQP in ascii terms > > - if that byte is 0, then the JMS client is expecting to have the server's > session being anonymous. > > 414D5150 -->00<-- 010000 > > > > With that I have two questions: > > - What is the SASL Anonymous for then if clients are expected to dictate > if they will use SASL or not? I was expecting it being a server's > directive.. to either use SASL or not? > > > - If you need that capability for sure.. there's currently no way to use > Proton to determine if we need SASL or not. The only way I could find was > to inspect the first byte 4 (starting at 0) on the protocol and initialize > SASL. > Couldn't (or Shouldn't?) we have an event such as SASL_INIT from Proton > and then we make the proper determination? > > Maybe I missed the proper API if there's a way around this already!
