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<--    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!
>> 
>> 

Reply via email to