On 25 February 2015 at 18:40, Andrew Stitcher <[email protected]> wrote: > On Wed, 2015-02-25 at 10:27 +0100, Jakub Scholz wrote: >> ... >> But I find this part a bit dangerous: >> "Classically in protocols where SASL was not optional the way to avoid >> double authentication was to use the EXTERNAL SASL mechanism. With AMQP, >> SASL is optional, so if SSL is used for client authentication the SASL >> layer could be entirely omitted and so using EXTERNAL is not necessary." >> > > This is really just a statement about how AMQP 1.0 works - if you like - > it is an aside praising the good protocol design sense of the standard's > authors (you know who you are!). > >> I understand the idea and I would even agree that this is the proper way >> how to do it in the long term. But I'm not sure whether all brokers support >> this concept. For example, I'm not sure whether you can configure the Qpid >> C++ broker in a way to accept AMQP 1.0 connections with SSL Client >> Authentication without SASL EXTERNAL while at the same time accepting AMQP >> 0-10 connections only with SASL EXTERNAL. Therefore I would be afraid that >> allowing SSL Client Authentication only without SASL could cause some >> serious incompatibilities - I think both should be possible / supported. > > And both are supported. > > The qpidd 0-10 support is not going to change. The qpidd 1.0 support is > on a different code path so there is little bleed over in functionality. > > The proton server code can auto detect which protocol layers the client > is using, and subject to it being an allowed protocol configuration, > authenticate it. > > Other AMQP 1.0 implementations may not support leaving out the SASL > layer and so you can certainly always tell the client to use it (even if > it adds no useful functionality as in the ANONYMOUS and EXTERNAL cases). > > So as far as the current plans for proton go if you require SSL client > authentication it will happen whether or not a SASL layer is there. > > As EXTERNAL and better SSL integration with the transport code is not > yet implemented there may be something significant I've missed in this > analysis, in which case it's all subject to change! > > I hope that helps. >
I'm going to post my comments here and on the wiki, as I dont think many (except maybe you) will actually see them on the wiki ;) Assuming I've read the email thread correctly, you do plan on implementing EXTERNAL so that clients can be authenticated using SSL client auth + EXTERNAL. I think that is a good idea, as even though it can be ommitted not all brokers or clients will want to support doing so. There may also be cases where implementations handle the SSL by themselves and only want to do SASL via proton (albeit by reading/writing bytes currently). Possibly less so on the C side, but almost everyone seems to do that with Proton-J. Mentioning Proton-J, are there any plans there? The completion of the SASL stage only being indicated by an event, combined with removal of the old read/write sasl bytes methods, seems to end any prospect of not using the events if you want SASL (at least, not without moving to intercepting the raw SASL frames before the transport). Does this mark the end of the old non-events API? The method for excluding certain server mechanisms seems a bit odd to me. A method to configure the mechanisms to be used feels like it might be a better fit (either ignoring mechanism that arent installed, or throwing to indicate they arent present, or making that a choice), what do you think? How does pn_transport_require_auth interact with old 'allow skip' functionality that let transports with SASL configured permit non-SASL connections? The two have different defaults, as skipping wasnt allowed previously (hence the old method being added), whereas apparently it now would be by default. That itself feels a little wrong to me, I think people should have to opt-in to that behaviour as they did previously. You mention removing deprecated APIs in the form of pn_sasl_client/pn_sasl_server. I think its worth mentioning these were only to become deprecated in 0.9. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
