On Oct 15, 2014, at 11:09 AM, Robbie Gemmell <[email protected]> wrote:
> 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. I thought about the even being generated before SASL headers were created. I event would work if implemented at the proper place. But if you already have a solution for that.. it's all good... thanks Robbie > > Robbie > > On 15 October 2014 15:15, Clebert Suconic <[email protected]> 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 <[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! >> >>
