What Ted already implemented on the C side would enable what you are seeking, allowing the server to be configured (depending on your security configuration; some wouldnt want the without-sasl case to ever work, other may allow it in no-auth scenarios) to accept either the sasl or non sasl header as the first bytes and respond appropriately. The JIRA for the Java side just hasnt been implemented yet.
Generating an event to say the sasl header was received might not work that well, as you currently need to pump the bytes into the transport for it to generate events, and it currently needs to know in advance how to process any bytes that come after the header (the client could for example pipeline the entire sasl 'negotiation' and well beyond, on assumption the authentication or lack thereof will be successfull). Making the sasl process interface nicer with the events stuff in general is something I would like to see happen, though not something I currently have time to look at though. Robbie On 15 October 2014 15:15, Clebert Suconic <csuco...@redhat.com> wrote: > 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 <robbie.gemm...@gmail.com> > 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 <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 > >> 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! > >
