What is LDAP and how is it used by DataPipe?
LDAP, Lightweight Directory Access Protocol, is an
Internet protocol that email and other programs use to
look up information from a server.
Every email program has a
personal address book, but how do you look up an address
for someone who's never sent you email? How can an
organization keep one centralized up-to-date phone book
that everybody has access to?
That question led software companies
such as Microsoft, IBM, Lotus, and Netscape to support a
standard called LDAP. "LDAP-aware" client programs can
ask LDAP servers to look up entries in a wide variety of
ways. LDAP servers index all the data in their entries,
and "filters" may be used to select just the person or
group you want and return just the information you want.
For example, here's an LDAP search translated into plain
English: "Search for all people located in Chicago whose
name contains "Fred" that have an email address. Please
return their full name, email, title, and description."
LDAP is not limited to contact
information or even information about people. LDAP is
used to look up encryption certificates, pointers to
printers and other services on a network, and provide
"single signon" where one password for a user is shared
between many services. LDAP is appropriate for any kind
of directory-like information, where fast lookups and
less-frequent updates are the norm.
As a protocol, LDAP does not define
how programs work on either the client or server side.
It defines the "language" used for client programs to
talk to servers (and servers to servers, too). On the
client side, a client may be an email program, a printer
browser, or an address book. The server may speak only
LDAP, or have other methods of sending and receiving
data—LDAP may just be an add-on method.
If you have an
email program (as opposed to web-based email), it
probably supports LDAP. Most LDAP clients can only read
from a server. Search abilities of clients (as seen in
email programs) vary widely. A few can write or update
information, but LDAP does not include security or
encryption. Therefore, updates usually require
additional protection such as an encrypted SSL
connection to the LDAP server.
LDAP also defines: Permissions:
set by the administrator to allow only certain people to
access the LDAP database, and optionally keep certain
data private. Schema: a way to describe the
format and attributes of data in the server. For
example: a schema entered in an LDAP server might define
a "groovyPerson" entry type, which has attributes of "instantMessageAddress"
and "coffeeRoastPreference". The normal attributes of
name, email address, etc., would be inherited from one
of the standard schemas, which are rooted in X.500 (see
LDAP was designed at the University of
Michigan to adapt a complex enterprise directory system
(called X.500) to the modern Internet. X.500 is too
complex to support on desktops and over the Internet, so
LDAP was created to provide this service "for the rest
LDAP servers exist at three levels:
There are big public servers, large organizational
servers at universities and corporations, and smaller
LDAP servers for workgroups. Most public servers from
around year 2000 have disappeared, although
directory.verisign.com exists for looking up X.509
certificates. The idea of publicly listing your email
address for the world to see, of course, has been
crushed by spam.
While LDAP didn't bring us the
worldwide email address book, it continues to be a
popular standard for communicating record-based,
directory-like data between programs.
I've always taken
it to mean for user authentication – “single signon” -
but I suppose the response to the question should be
something like “In what way?” or “For what information?”
because LDAP can be used in several ways (see above).
: As you know DataPipe takes its user ID info from the
client; where it gets its info from – a domain, Active
Directory, LDAP, PeopleSoft, NetWare, etc. – is
irrelevant. If not returned to DP by the standard
call, we have the hooks in DP such that another method
can be written and used in place of the standard
DataPipe call; this would take coding specific to the
customer’s needs, but we’ve put the ability into
DataPipe for it. Certainly, we don’t use LDAP for
database queries. DataPipe has its own permissions
so we don’t use LDAP for determining who can “see and do
what” on a particular DataPipe form.
But since DataPipe can take the user ID info from
the client LDAP can certainly be a source for that