directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: SASL in the client API
Date Fri, 15 Apr 2011 07:48:10 GMT
On 4/15/11 9:01 AM, Pierre-Arnaud Marcelot wrote:
> 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.

It was a good thing, but in fact the Java Sasl implementation already 
stores those values, AFAICT.
> 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.

We do, but we should not have the DigestMd5Request, CramMD5Request and 
GssApiRequest classes extending a SaslRequest containing the parameters 
already present in the SaslClient classes, that's what I'm currently 
thinking.
> To me, the basic idea was that the casual LDAP user should not know about the SASL implementation
and/or the SaslClient classes.
Totally agree.Md5( ...)
> 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).
I have to dig further. I took the problem by the other side in fact :
- I wanted to create a SASL BindRequest, and I hit a wall fast. Maybe I 
should have a look at the current LdapNetworkConnection code to see how 
it works for the existing mechanism (MD5 and GSSAPI), instead of trying 
to write the same thing for EXTERNAL and PLAIN from scratch...

Thanks for the enlighments, Pierre-Arnaud !


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message