I think you should have an event for SASL_NEGOTATION.. or any name you chose.. then you could negotiate it properly. I don't think it would be too hard to implement.
The clients I'm working don't know how to negotiate ANONYMOUS. All the Java clients I'm dealing with now will throw a bad NPE if I don't have this behaviour. Should we raise a JIRA? On Oct 15, 2014, at 6:07 AM, Robbie Gemmell <[email protected]> wrote: > 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!
