Re: SASL / non SASL connections...
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--01 * 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-- 01 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!
Re: SASL / non SASL connections...
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--01 * 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-- 01 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
Re: SASL / non SASL connections...
On Oct 15, 2014, at 11:09 AM, Robbie Gemmell robbie.gemm...@gmail.com 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 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--01 * 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-- 01 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
SASL / non SASL connections...
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--01 * 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-- 01 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!
