qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: Proposed SASL changes (API and functional)
Date Thu, 26 Feb 2015 12:28:20 GMT
On 25 February 2015 at 18:40, Andrew Stitcher <astitcher@redhat.com> 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.


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message