apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: LDAP changes in apr-util 1.0.x
Date Wed, 05 Jan 2005 22:33:37 GMT
William A. Rowe, Jr. wrote:

> Ewww... IIUC - apr_ldap_initialize("ldaps://foo/") was supposed to
> handle the ssl 'crap' for us.  If we are just exposing OpenLDAP and
> Novell LDAP, -1 for this change, and I'd like to propose we deprecate
> the whole shooting match for ldap.

apr_ldap_initialise() presently makes the erroneous assumption that you 
only ever want to specify one certificate per connection.

Perhaps a better way of doing this is to allow the apr_ldap_initialise() 
function to be called more than once - if you want two certs, just call 
apr_ldap_initialise() twice. This removes the need to have a separate 
apr_ldap_ssl_add_cert() function entirely.

Another fun issue is support for client certificates. No provision has 
been made to pass client certificates to apr_ldap_init(). I spent some 
time Googling for "best practises" for doing SSL/TLS in LDAP, and the 
consensus seems to be that all the weird ldap*ssl*init() and 
ldap*start*tls*s() functions are deprecated in favour of setting all TLS 
related parameters via ldap_set_option(). This is the thinking behind 
adding the apr_ldap_option API.

Current LDAP best practise seems to be:

- call ldap_init() once.

- call ldap_set_option() zero or more times, specifying SSL mode (SSL, 
STARTTLS, none), client certs, CA certs, whatever.

- call apr_ldap_bind() to actually bind to the server.

The question now is, can we emulate the above simple approach in APR by 
hiding ldap_start_tls_s() and ldap_ssl_add_cert() and all the other 
nonsense inside ldap_set_option()?

The APR LDAP stuff is designed to fail cleanly - if something cannot be 
done, APR returns a human readable message explaining as best as it can 
what could not be done, to save the calling application from having to 
jump through hoops translating error codes into something a human can 
understand. This means that we do not have to implement every single 
feature in every single toolkit, if something is not practical we can 
gracefully bow out and say "sorry, but what you just tried to do isn't 
supported in this toolkit (yet)".


View raw message