apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: LDAP changes in apr-util 1.0.x
Date Wed, 05 Jan 2005 23:56:04 GMT
   The problem is that other SDKs such as Novell, do not use
ldap_set_option() to set the certificates or the SSL mode.  Novell uses
ldapssl_add_trusted_cert() and ldapssl_start_tls().  As it stands the
apr_ldap_add_cert() function allows you to add as many certificates as
you like doing the correct thing for all SDKs under the covers. 
apr_ldap_init() is doing the right thing as far as starting SSL, TLS or
clear ldap connection regardless of the SDK.  Using
apr_ldap_set_option() to set certificates or SSL modes would be SDK
specific.  It has to be abstracted by APR.


>>> Graham Leggett <minfrin@sharp.fm> Wednesday, January 05, 2005
3:33:37 PM >>>
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
> 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
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
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