Cameron Laird's personal developer's perspective on LDAP
Table of contents
LDAP provides a common way to access different directories.
[X.500 history, ...]
[Protocol, schema, language, directory, meta-directory (1998), ...]
[data management; client-server; ...; poor fit?]
[Not only people. Resources--printers, ...--'nother good example.]
[Explain poles of UMi and Netscape.]
Netscape has much the most prominent LDAP profile of any
organization. It employs [...]; as many of its products
as can be (including [...]) are LDAP-enabled; it freely
provides a
range
of LDAP tools, and [...]
[Explain roles of Microsoft and Novell.]
[Explain IBM, ...]
[Refer to published article comparing servers. Explain
position of Microsoft's Site Server (3).]
Several organizations expose LDAP directories to the Internet
public at large. It's becoming more and more common to point
e-mail clients, for example, to such public resources as
- ldap.bigfoot.com
- ldap.four11.com
- ldap.infospace.com
- ldap.switchboard.com
- ldap.whowhere.com
- ldap.yahoo.com
Language choice
Whatever your domain, use a high-level language. Functional bindings
are available for
- Eiffel
- Java: Netscape makes many resources (well, if you use a sufficiently
recent release of its browser)
available for LDAP, including its
LDAP Java Classes 3.0 Release
- (server-side) JavaScript:
- Perl: CPAN includes both
perl-ldap-0.09
and
Net-LDAPapi-1.42.
I've used neither. Gaining mindshare in 1998 is Netscape's
PerLDAP.
This uses a rather "deep" object-oriented coding style, and requires
Netscape's C-bound SDK for its construction.
- PHP
has a good LDAP module, as Rasmus Lerdorf
explains
for Web Techniques. Rasmus also describes in this
article the
wise use he makes of IMAP and Pine to manage his address book
conveniently, and writes a companion piece on
OpenLDAP
installation.
- Python,
which has a well-supported
LDAP
module. [Is this the one built with Netscape's SDK, or the other?]
- Tcl:
Tony Murray released
tclLDAP-2.1
late in 1997. NeoSoft
has an even slicker
binding,
which it generally distributes as one of several values
of its
Neotcl
bundled distribution.
This
is the 8.0.3-1 release. NeoSoft's LDAP from early 1999 supports
Netscape's Directory Server library, and, with perhaps a tweak in
the makefile to accomodate
filenames which embed version information, the latest UMich
release. [Explain archives, compatibility, ...]
Summer 2000 update: LDAPTcl is available as contrib/ldaptcl
from the OpenLDAP sources.
Sensus Consulting Ltd.
also has a several-years'-mature
binding
of Tcl and LDAP.
- Visual Basic:
- [others]
and one of these absolutely should be your vehicle of choice.
There are no deep problems using the C API directly, just the
usual tedium and wasted motion. Scripting languages are ideal
for LDAP; their portability often is a good match for
organizational client-side requirements (and more), and there's
no performance constraint for all the network-bound
LDAP applications I've seen.
Performance tips
I have a large collection of performance results I'll report as 1999
goes on.
getpwnam vs. C-coded LDAP
Digital Unix, mediocre hard disk; 12500+ lines in /etc/passwd and
as cn attributes in Netscape 3.0 Directory Server bundled
(Berkeley DB) LDAP data store.
getpwnam takes 0.03-0.08 seconds. LDAP authentication of single
cn is 0.025. Once LDAP connection is properly initialized and
bound, lookups of incremental cn-s take under 0.01 seconds.
We contributed
"A
beginner's guide to directory development"
to the July 1999 SunWorld, and
"A
Guide to LDAP Servers" two months later. Brian Vincent's
comment
about it for LinuxToday makes us feel successful: he mentions
how confusing it is to start with OpenLDAP (Is an error a problem
in generation? Configuration? ...), and that with this article
and an OpenLDAP RPM he had a working installation in 45 minutes.
That's just what we're after.
Mark Komarinski and Cary Collett wrote an
introduction
to LDAP for LinuxWorld which complements our
treatment. We plan a follow-up in September
on schema design, performance, and other intermediate topics.
Suggestions are welcome.
In documenting the sl{a,ur}pd server installations, the UMich
team sets the context with a level-headed
introduction
to the key notion of "directory service". My thanks to
Jean-Claude Wippler for pointing out this section of the essential
SLAPD
and SLURPD Administrators Guide.
Topical remarks on LDAP appear in a
February
1999 "WebAdmin" column we did for WebServer Online,
reprinted as "LDAP
Comes of Age" in Server/Workstation Expert.
The leading standard references are
[Standard text. Critique.]
[Explain newsgroups and mailing list. Explain
archive
for the LDAP mailing list]
[Link to other articles.]
Several RFCs govern LDAP, among which I most often consider
- 1823: Howes' and Smith's API definition
- 2254: LDAP search filter syntax [doesn't this supersede 1960?]
- 2255: the LDAP URL.
- 2256: LDAPv3 and the X.500 user schema
Also important: the
draft IETF standard on the C API.
Dave Kosiur wrote one of the nicest
introductions
to LDAP back in 1996, for SunWorld Online.
Rawn Shah does his usual thorough, well-informed, lucid
treatment in a series for
for LinuxWorld. The
first
part introduces LDAP; the
second
counsels creation of a "directory task force" for
managing directory development; and ...
Netscape sponsored a good
interview
with Tim Howes.
Sun.Net
is an intriguing example of what LDAP can do.
An
article in InfoWorld gives the executive summary on LDAP.
Will the
Directory
Interoperability Forum take off? 'Beats me.
I'm seeking comments from several of the players.
I'm ambivalent about LDAP. Professionally, of course, I'd
like to see it expand, simply because my experience gives
me a comparative advantage in the marketplace. However,
I'm still not sure which questions LDAP truly answers,
and whether other technologies don't provide better ones.
At one extreme, for example, it's still unclear to me
what the precise advantage is to clients to obtain data through
an LDAP interface rather than a more general DBMS.
On another side, XML has a lot of attention, and is appearing
in applications that are at least technically feasible with
LDAP. Will DBMSs and XML squeeze into non-viability the
LDAP niche?
Also, LDAP has a little of the feel of ISDN in the USA: for several
years now, this was to have been the year of its
widespread acceptance. I'm not convinced that we know
yet what the key questions are about LDAP. Is the replication
challenge holding it back (that's my favorite--to me, it looks
as though LDAP won't get replication right before 2000, at the
earliest)? Is it the
victim of the collateral fog generated by Microsoft's marketeers
in their attempts to cover up the poverty of their own directory
offerings? Are meta-directory services what people really need?
I don't yet know. I know several development teams who say
they're ready to enable LDAP interfaces in various products,
as soon as customer demand reaches critical levels--but it
hasn't happened yet.
"Is LDAP replacing X.500?" It beats me. Keep in mind that
LDAP originated as a (lighter-weight) gateway to
X.500. They certainly can co-operate technically. Whether
organizations understand that, and how they react commercially,
is another question (and another one I can't answer).
[my projects: AVF; scripting; portability; usage; replication;
sourcing; IMAP?; categories of content]
[pitfalls: strategic decision; negative benefits; polysemy; ...]
[Explain OpenLDAP. Note
various bindings (including recent Tcl one).]
Cameron
Laird's personal notes on
LDAP/claird@phaseit.net