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 later. >>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. Regards, Graham --
