apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [Patch] LDAP SSL support for Tivoli
Date Sat, 01 Dec 2007 17:06:04 GMT
Eric Covener wrote:

> ldap_ssl_client_init() should be called once per process, not once per
> connection.

The LDAP SDK uses the ldap_set_option function for both once-per-process 
values (LDAP* is NULL) and once-per-connection values, and 
apr_ldap_set_option follows this pattern as well.

Remember that one of the basic design goals of the APR LDAP code is to 
offer a consistent interface to 8 distinct APR LDAP clients, regardless 
of the underlying LDAP implementation, and this has been a mindbending 
task. Adding init code exclusively to apr_ldap_ssl_init() instead of 
apr_ldap_set_option() makes the Tivoli support work differently to the 
support maintained by other toolkits, and introduces inconsistent 
behaviour, which is exactly what the API is trying to avoid.

> While the z/os manual says calling into ldap_ssl_client_init()
> repeatedly just produces error, I've seen some reports that doing so
> with different values (for the keyring) does have affect (on non-z/OS,
> where this SDK is equally useful).

Attempting to call ldap_ssl_client_init() on a per-connection basis will 
return an error as per the patch, so this is maintained.

> It also struck me as a little odd that in apr_ldap_init (establish a
> connection) calling  apr_ldap_set_option(..., APR_LDAP_OPT_TLS) wasn't
> conditional on SSL in either form being requested.

A user might choose to open a normal connection first, and an SSL 
connection later, and the toolkit must be given the opportunity to be 
able to initialise the SSL before the first connection.

It cannot be assumed that other toolkits may be able to be further 
configured after the first LDAP connection is established.

> From a general 1.3 perspective, the Tivoli and z/OS LDAP SDK problem
> with client certs is resolvable by allowing apr_ldap_init() be passed
> something indicating client cert selection (these SDKS must specify
> the client cert "label" at connection time). Just mentioning in this
> case this meshes with anything else you're looking at.

According to the Tivoli docs, the client code will either choose the 
default client cert in the CMS store, or will rely on an environment 

Supporting a certificate label isn't something easily done within the 
current API, and the API cannot be changed until APR v2.


View raw message