Welcome Guest. | Log In| Register | Membership Benefits

InformationWeek Labs
June 22, 1998

Manage Custom Apps With LDAP

New toolkits offer standard interface for accessing directory services
By Don Kiely

First Look T he Internet's Lightweight Directory Access Protocol is gaining popularity, with several major vendors offering LDAP toolkits to let developers directory-enable custom applications.

The primary objective of distributed computing is fast becoming universal access to directories of complex and free-form data scattered across corporate networks and the Internet. Such information can be placed in a centralized location in a common format, or can be left distributed around the network and in applications written to access the data wherever and in whatever form it is. Either method means a major overhaul of a company's IT strategy.

Before the X.500 and LDAP specifications were introduced (see story, "X.500, LDAP: Evolutionary Steps In Directory Access"), enabling applications to access directory data required one or more of the following approaches, and all such features had to be designed from scratch for each application:

  • an application-specific, private database local to a desktop or server, probably shared across workgroups;
  • an application-specific, networked, client-server directory using proprietary access and replication protocols, with limited support for cross-application use;
  • a custom directory database specially designed for a specific organization's in-house applications;
  • directory services for applications standardized on a proprietary network operating system, such as Novell Directory Services.
These traditional approaches have resulted in the proliferation of directories that an organization must manage and synchronize across custom applications and across disparate servers and desktops. Divergent directories have also prevented productive sharing of directory information across applications and software vendors.

The software industry has conceded that innovation will inevitably lead to the development of even more incompatible directory formats, so it has developed standards for a uniform interface to directory data. The X.500 specification provides a complex specification both for directory servers and for the protocols used to access such directories. Widespread adoption of such a standard demanded a simpler specification for client access to directory servers, and LDAP was born. With LDAP, adding directory services to an application is feasible, which fueled widespread support for the specification.

Why should application developers and IT departments consider implementing directory services, and specifically LDAP services, in their applications? Instead of repeatedly developing custom directories of information, developers can have instant access to multiple directories both inside and outside the organization, using standard Internet protocols. Development costs are lowered by avoiding the need to build and maintain application-specific directories. And, depending on the tools used to add directory features, the application automatically supports multiple platform and directory environments.

Here are a few of the ways that custom applications can benefit from access to LDAP directories:

  • server and client applications accessing a centralized directory of user account and authentication information to simplify password management;
  • Web- and messaging-based intranet applications that search and retrieve user information such as certificates, E-mail addresses, privilege attributes, group membership, and organizational position, to route application data and forms to support custom access control and application logic;
  • storage of client application settings and other user-context information in a centralized directory to enable desktop-independence and centralized management of desktop applications;
  • extranet front-end applications that require frequent queries and high-performance selective retrieval of structured information across firewalls;
  • synchronization or data transfer between different types of directories within the same organization--say between a Netscape Directory Server and Novell Directory Services;
  • coordinating with other networked application instances by persistently storing and retrieving shared configuration, named resources, and other key information through a directory.
Distributing LDAP-enabled applications requires some care, depending on the directories that clients and customers already have available. This is a particular concern for shrink-wrapped applications, which have to contend with any and all existing environments on target platforms.

If users have an LDAP- or X.500-compliant directory, your application just needs to tie into it. If they don't have a directory implemented, you can require that they implement one before installing and using your application, or you can build a directory with your application.

Major software vendors are developing toolkits that provide a standard interface for accessing directory services in custom applications. These include products from IBM, Microsoft, Netscape, Novell, and Sun Microsystems' JavaSoft unit. LDAP is a relatively new standard, and several toolkits are available only as betas. But all these vendors are working furiously to ship the toolkits, and I found all the products to be reasonably stable.

continued...page 2, 3


Back to Labs

Send Us Your Feedback

Top of the Page