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, > > 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. > > 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 > > internally, we handle the challenge/response dialog. > > 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. > > This is what I'm going to investigate in the next couple of days. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
