IBM Application Framework for e-business - Directory Services


The IBM Application Framework for e-business is designed to enable businesses to build and deploy Web-based applications quickly and easily. To accomplish this goal, the architecture is based on open standards that have been or are being widely adopted by the computer industry. This paper focuses on directory services which are a major component of the framework's network infrastructure. Refer to the Network Infrastructure Overview and the Architecture Overview white papers for more information on other aspects of the architecture.

Introduction

A directory service is simply a repository of information, combined with an access method and related services, that stores location and other detailed information about resources such as users and servers. A good example of a directory is the telephone book which contains the names, addresses, telephone numbers and (in some cases) services of people and businesses. Such information can be retrieved by name (white pages) or service categories (yellow pages).

Within a business organization's intranet, directories are used to store information about employees - name, phone number, e-mail address as well as user preferences, user applications, etc. Directories are also used to store the location and attributes of different resources such as file servers, application servers, and printers. For example, attributes of a print object would include the server name, speed, and location of the printer. Directories allow users and applications to quickly locate resources with the specific characteristics needed for a particular task. They also enable a thin client, roaming user environment in which users can sign on from any client and completely rebuild their desktop based on information in the directory.

Although directory services have been used in limited forms for decades, the explosion of distributed and Internet-based computing in the 1990s has driven the widespread proliferation of many types of directory services throughout every type of customer. Forrester Research recently reported that the typical Fortune 1000 corporation has 181 different directories in the enterprise. The lack of standards has resulted in each of these directories storing and managing application-related information in its own proprietary way. ERP applications, data base applications, operating systems, and e-mail/messaging systems all have their own way to define and store common objects such as people, groups, distribution lists, etc. As a result, management and synchronization of multiple directories constitute a major expense for an organization.

Now that directory standards are emerging, the opportunity exists for enterprises to simplify their directory mayhem. If an enterprise is able to store directory information once, and administer it in one place, the total cost of maintaining this information is significantly reduced. However, in many enterprises, specific application requirements and migration costs dictate that many different directories continue to be maintained. In these environments, directory standards enable central administration and reduce the cost and complexity of synchronization.

Given the distributed and heterogeneous nature of network computing, the framework's directory architecture is defined to satisfy the following requirements:

Directory Services Architecture

Directory services provide the capabilities to store, modify, delete and retrieve information in a logically centralized repository using open, standard APIs. Information stored in the directory is typically accessed for read only, changes infrequently and is centrally managed and updated by an administration facility. As part of the Application Framework for e-business, IBM has defined a standards-based directory architecture to address the requirements of directory based enterprise computing.

The framework's directory architecture contains the following key elements:

Following is a more detailed discussion on the key components of the directory architecture.

LDAP Directory Client and Server

LDAP defines a client / server distributed directory service. Users of the service perform operations (add, delete, modify, and search) on information stored in the directory using industry standard LDAP and JNDI APIs. In many cases, LDAP clients and servers execute on different platforms and clients communicate with servers using standard LDAP protocols. Directory-enabled applications, however, are usually not aware of the distributed nature of the service.

LDAP client functionality can also be accessed indirectly from any Web browser through Internet protocols such as HTTP and HTTPS. In such a scenario, the browser sends the user's request to the Web server which interprets the request and invokes an application. To satisfy the request, the application invokes the LDAP client (via LDAP or JNDI APIs) to obtain information from a directory server.

LDAP servers store information in a repository, usually a database or a file system. In most cases, the directory contents of an enterprise will not be maintained on a single physical directory server. Instead, portions of the hierarchical directory tree will be maintained on different directory servers. To accommodate such an environment, the LDAP protocol provides referral support in which a client request for directory information not maintained on a specific server can be referred to a different server which can satisfy the request.

To improve scalability and performance, directory information can actually be stored on multiple LDAP servers. The LDAP architecture provides mechanisms for replicating the directory contents. Thus, multiple copies of the data will exist, enhancing the scalability as well as availability of the directory service. This replication functionality is not visible to the users of the directory service.

Common Schema

The directory schema defines the rules by which objects are stored in and retrieved from the directory. Directory information is stored in entries which are referenced via a distinguished name in the hierarchical namespace. Specifically, directory schema defines the rules for what objects are stored in the directory and what attributes an entry must and/or may contain.

In conjunction with LDAP APIs and protocols, defining and supporting common standards-based schema for key objects such as users, groups, roles, and network policies allows network computing-based applications to be written independent of specific directory implementations. Common schema also has a positive affect on reducing administrative costs and complexity. An object can be defined once within an enterprise and accessed in a consistent manner by multiple different applications as compared to today's environment in which common objects must be defined and administered on a per-application basis.

Industry standards which influence the framework's schema include:

Meta Directory

The heterogeneous environment of network computing will require the coexistence of multiple directories within an organization's intranets. Each directory may be accessed by its native clients and APIs, and managed by its native administration tools. Most of the time, objects will exist in more than one of these directories. For example, an e-person's object (which represents a user) may exist in an LDAP directory, Domino directory and an NT directory, with possibly different attributes in each directory.

Management and synchronization of the information of these directories constitutes a major overhead for the organization. When an object is added to one of the directories, the object will be visible only to clients of that directory. To make it available to clients of other directories, the administrator must add the object to each directory using that directory's native tools. This is a major administration effort and is subject to mistakes throughout its implementation. In addition, there is no guarantee that the object will be updated in all directories in a timely and consistent fashion when changes are made to the object.

The Application Framework for e-business provides a set of meta directory functions to synchronize the information in multiple directories, and simplify the management of these directories. Towards this end, an LDAP-based master directory is defined. This directory contains a superset of the information in all the intranet's directories (these directories are referred to as slave directories). If a common schema is supported for all slave directories, the attributes for an object will be the same in all directories. The directory, however, accounts for the situation when the attributes for an object (and indeed, the schema for storing the object) are different for the slave directories. The set of attributes for each object in the master directory is defined to be a superset of attributes for the object in all other directories.

The following meta directory functions are required, and tools are provided to execute these functions:

It is recommended that updates and administration of directory contents occur at the master directory. The synchronization function from slaves to the master is provided for the cases when an administrator for one of the slave directories does not have access to the master directory administration tools, or when a slave directory allows its users to update their personal data (such as personal phone number) in that directory.

Summary

Directory services are a key part of the Application Framework for e-business network infrastructure and a critical component for maintaining and accessing information on users, applications and services in both intranet and Internet environments. To improve the portability of directory-enabled applications and reduce the cost and complexity of directory management, directory services are based on standard APIs, protocols, and schema definitions. The Application Framework for e-business recognizes the fact that heterogeneous directory environments will continue to exist for some time. To support such environments, the framework provides meta directory services which form the basis for central administration of information.

IETF RFCs

The following IETF RFCs are currently being worked for LDAP Version 2 and Version 3.