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 Fri, 07 Jan 2005 08:28:52 GMT
William A. Rowe, Jr. said:

>>>Wouldn't it be *much* more economical to do something similar
>>>to apr_procattr_t, where we set up all the choices beforehand,
>>>and can reuse the apr_ldapopt_t over and over on each ldap
>>>connection for options which do not change?
>>All the LDAP toolkits have this concept already - you just call
>> ldap_set_option with a NULL ldap handle and you set system wide
>> properties (like defaults, and SSL params).
> I ment from the perspective of apr_ldap() - for both an individual
> setting and global config.

The trouble is that the LDAP toolkits give you two choices: system wide
options, and per connection options tracked with a connection handle.
Creating our own system wide apr_ldapopt_t isn't going to do anything for
us that ldap_set_option() can't do for us already.

The LDAP best practice seems to be:

- set system defaults using ldap_set_option(NULL, ...)
- create a possible connection using ldap_init()
- optionally modify the connection (adding SSL, or TLS, or client certs,
or whatever) using ldap_set_option()
- actually make the connection using ldap_bind()

I think we should stick as close to this as possible. So far OpenLDAP can
fit this model, Novell can fit the model (by hiding ldap_start_tls_s and
friends inside ldap_set_option), and Microsoft can handle this (like
openldap, all the params can be set using ldap_set_option).

APR doesn't allow us to remove functions until v2.x, so I am very keen to
avoid adding arbitrary functions to APR and then regret their addition

>>The issue is the supporting of client certificates - which in some cases
>> (openldap, microsoft) are set on a per connection basis (which makes the
>> most sense), and in other cases are set on a system wide sense (novell in
>> my understanding).
> Yes, it will vary a bit.  The global flavor apr_ldap_default_set()
> would be supported mostly everywhere, and per-connection options
> passed to apr_ldap_init() would be supported only if available.

apr_ldap_default_set() can be achieved already by using
apr_ldap_set_option(NULL, ...), and if the end user has used LDAP toolkits
before (likely) they will expect APR to work in a similar way. I think we
should keep to the principle of lease astonishment if we possibly can.

>>Not only do we have to somehow handle this in APR, but we also need to
>> handle this in httpd. Perhaps we need an httpd directive with global only
>> scope that sets "system wide" certificates (AKA CA certs, but in the
>> Novell case it could also be a client side cert valid system wide), as
>> well as a local scoped per connection directive for "client certificates"
>> (ie a per connection client cert, supported by Microsoft and OpenLDAP but
>> fails with a graceful error on Novell).
> Well, the very same directives in the global config would help
> choose the 'default', while if restricted to a single ldap entry
> they would apply only to that host.

I would still recommend keeping separate httpd config directives for
"system" certs and "client" (per connection) certs.

I have learned more about the Novell toolkit: Unlike the other toolkits,
where CA certs are set all in one go, Novell expects you to specify
multiple CA certs separately, one at a time. The easiest way to achieve
this is to specify LDAPTrustedCA more than once.

Novell client certs are specified using a different API, we can hide this
inside apr_ldap_set_option() and we are laughing.


View raw message