[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: certificate mapping (Was: Netscape SLAPI -- IBM contribution to OpenLDAP)

Kurt D. Zeilenga wrote:

At 10:57 AM 2001-12-03, Kartik Subbarao wrote:

One question -- does this implementation include the certificate
mapping API capabilities that Netscape also provides, or would that
need to be implemented separately?

I'm not sure exactly what features other vendors provide. Can you describe these?

The docs for the Netscape certificate mapping API that I'm referring to are here:


Basically, it allows you to customize the certificate-to-DN mapping process very flexibly. For example, let's say that

1) Each employee's certificate has the following attributes:

OU=Employment Status - Employees

2) Each server certificate has the following attributes:


3) The LDAP Directory has the following structure:

ou=Employees, o=corp.com => contains Employee entries
ou=Servers, o=corp.com => contains Server entries

Now, let's say you want to be able to map employee and server certificates to the appropriate entries in the directory. The certificate mapping API lets you write code to pull out the OU attribute from the cert, and make custom decisions on it, like the following:

ou = get_ou_from_cert();
if (ou == "Employment Status - Employees") {
  uidattr = get_uid_from_cert();
  entry = ldap_search(base => "ou=Employees, o=corp.com",
                      filter => "(uid=" uidattr ")");
else if (ou == "Servers") {
  cnattr = get_cn_from_cert();
  entry = ldap_search(base => "ou=Servers, o=corp.com",
                      filter => "(cn=" cnattr ")");

dn = entry->get_dn();

Then you can use the DN as the mapped DN for the purpose of ACI rules,

One of the things holding us back

from using OpenLDAP more broadly is the current lack of ability to map

an SSL client certificate to a DN in the directory, and use that DN in
ACIs, etc.

This is actually possible today. That is, when SASL EXTERNAL is used with TLS (SSL), the TLS layer provides SASL with the authentication identity (a DN), which is then mapped onto into a LDAP authzid, which is then mapped to a subject DN for access control evaluation.

Well, that sounds a lot more involved than the standard SSL client certificate-based authentication. We need to be able to support clients that make the following kind of API call:


This is the ldapssl_clientauth_init() function, which would be invoked with
client certificate information. Also equivalent is the -K option to Netscape's ldapsearch command. Is this something that OpenLDAP could support?

Caveat: my SSL/TLS expertise is not as high as most
folks in this august forum, so please be kind if I screwed up and
oversimplified something :-)