On Wed Jan 3 02:09:31 2007, Henry B. Hotz wrote:
The SASL API is already pretty complex for what it does IMO. (Why
isn't there a call that does both sasl_client_init() and
sasl_client_new()? Why does every app need 10++ lines in front of
sasl_{client,server}_new() to do two getnameinfo()'s and two
snprintf's, instead of just handing over the sockaddr's? Why. . .
? Obviously, I'm still getting familiar with things.)
I can answer some of that. sasl_client_init() does one-time
initialization, whereas sasl_client_new() does per-connection
initialization.
Unless you can tell me that there is a properly-documented API for
an ACAP library that's deployed on as many platforms (including
Java) as SASL already is, *AND* that it's no harder to
write/modify an application to use ACAP than it is to use SASL,
then I'm not interested. Sorry. You're welcome to try to
convince me, but it sounds off-topic for this list.
ACAP is merely an example of a protocol that got the SASL profile
right, not a replacement for SASL. It does the full range of
signalling required, so you know what to do on failure, and it also
handles both initial responses and data on success, to drop the
round-trip count.
In my current experiments Cyrus SASL doesn't appear to work when
you call sasl_client_start() with the second mechanism to try.
There are a lot of variables here, and a better-than-even chance
the problem is in my code, not the library. Once I have something
properly working I'll revisit this issue. I gather you're
claiming that ACAP solves this (and other) problems. See above.
No, sasl_client_new() is once per connection. sasl_client_start() is
once per authentication attempt. <sasl/sasl.h> has some useful
documentation, look for "Basic client model".
On Dec 19, 2006, at 1:23 AM, Dave Cridland wrote:
On Mon Dec 18 22:12:03 2006, Alexey Melnikov wrote:
Henry B. Hotz wrote:
The published sample code seems to only try the first mechanism
and then quit. I'm told the "correct" way to do SASL is to try
all the mechanisms (or at least all the ones supported) and
don't quit until you've tried them all. Is there any example
code that illustrates this?
(I wanted to point you to Cyrus imtest, but it doesn't do that).
In general, I think a well written SASL client should behave as
follows:
It should sort SASL mechanisms that both client and server
support by their "strength" or features recognized by the
client. For SASL mechanisms with equal strength the order used
by the server can be used.
The client starts iterating through the ordered list, starting
from the strongest mechanism. It tries the mechanism. If
authentication succeeds - success. If not, the client may retry
the mechanism (e.g. if the server returned an indication that the
password is incorrect) several times, say 3 times. After that
the client should move on to the next strongest SASL mechanism
and so on.
There are of course some complications. Some SASL mechanisms that
can potentially be stronger can end up being weaker, because of
the options that the server supports.
There are more complications than that - some protocols give you a
fairly wide set of protocol-level data about why a SASL exchange
failed, others don't. For example, IMAP will give you a pretty
simple "NO" for any failure at all, whereas ACAP will tell you
rather more, such as AUTH-TOO-WEAK, ENCRYPT-NEEDED, TRANSITION-
NEEDED, etc, which can be used by the client to figure out what
the next action should be.
Working examples? I'm modifying the PostgreSQL protocol as needed.
Adding SASL data to existing messages is easy. Adding an
AuthenticationContinue message isn't very hard either because they
have a protocol manual that's quite nice.
Right, so for the protocol, look at how ACAP does it.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
