Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates
 74.125.82.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=hnx80C3EyfYmNSvxEdY4LIN5zZ0WSt5w8kG4bZckZ7qB3DZqsR0zAVdBJCTQiVIgmf
         oXNpBKB3oggDTcc+CmJCE5MERsgslaxt0nlV3DdGWBtYt/nV5EoPnIOFGyac0ZLHOH3G
         9D98SNmd+pSwmTB4bOnbSs89aa6nvzDHX3tD8=
Sender: Pierre-Arnaud Marcelot <pajbam@gmail.com>
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: SASL in the client API
From: Pierre-Arnaud Marcelot <pa@marcelot.net>
In-Reply-To: <4DA76E40.7020304@gmail.com>
Date: Fri, 15 Apr 2011 09:01:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <582E6E78-D9D2-41FC-B03B-CBBAB41C2DA8@marcelot.net>
References: <4DA76E40.7020304@gmail.com>
To: "Apache Directory Developers List" <dev@directory.apache.org>

Hi Emmanuel,

AFAIR (I'm the one who created those three classes and their abstract =
superclass) the idea was to be able to store all the client parameters =
(login, password, various SASL settings) in simple classes. These =
classes being used with an LDAP Connection via a bind request.

I'll have to look in the code, but I think that we've used the =
SaslClient class internally to manage the challenge/response dialog, ie. =
we haven't (hopefully) reimplemented everything.
Have a look at the LdapNetworkConnection.bindSasl(...) method.

To me, the basic idea was that the casual LDAP user should not know =
about the SASL implementation and/or the SaslClient classes. He only =
uses our simple API classes to describes the LDAP bind requests (with =
SASL) and lets the API do all the work without worrying about complex =
encryption mechanisms, challenge/response, or having to learn another =
complex API (the SaslClient API).

Regards,
Pierre-Arnaud

On 14 avr. 2011, at 23:59, Emmanuel Lecharny wrote:

> Hi guys,
>=20
> I'm having some hard time with SASL handling on the client side. =
Currently, we support CRAM-MD5, DIGEST-MD5 and GSSAPI mechanisms, but =
the PLAIN en EXTERNAL mechanisms are not supported.
>=20
> So I decided to implement the PLAIN mechanism which is supported by =
the server, and I found that we have an approach that could be improved. =
Currently, we have re-implemented the full mechanism, and we have some =
dedicated class for each mechanism :
> - CramMd5Request
> - DigestMd5Request
> - GssApiRequest
>=20
> internally, we handle the challenge/response dialog.
>=20
> That's fine, but we could have use the Java SaslClient classes to do =
the same thing. Even better, we could also merge the way the server =
handle SASL with the client side.
>=20
> This is what I'm going to investigate in the next couple of days.
>=20
> --=20
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>=20