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%d126.96.36.199 header, and then if successfull proceed to establish the
'regular' AMQP connection over it beginning with the AMQP%d0.1.0.0 header.
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
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.
On 14 October 2014 19:20, Clebert Suconic <csuco...@redhat.com> 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
> 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!