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.
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 must be based on existing or emerging standards when available. Access to directory services must be available from a variety of client platforms through a standard Web browser. Common schema for universal objects, such as users and groups, must be standardized to eliminate application dependence on specific directory implementations. Information maintained in existing directories must be accessible without requiring a complete migration to a new directory. Central administration of common objects stored in multiple, different directories must be provided. Directory services must be secure. Access to information in the directory must be guaranteed for authorized users and denied for non-authorized users. In addition, the directory architecture must allow for storage and management of security information. Directory services must be available when needed by applications.
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:
!
Standards-based LDAP client and server LDAP, the light weight directory access protocol, was developed to provide standards for accessing the data in network directories. The LDAP distributed architecture supports scalable directory services with server replication capabilities (being defined for IETF LDAP version 3)
!
!
ensuring that directory data is available when needed. For security, LDAP supports both basic client authentication using a distinguished name and password, and SSL (Secure Socket Layer) which provides mutual authentication between the client and server as well as data security via encryption. LDAP version 3 supports the Simple Authentication and Security Layer (SASL), a framework for adding additional authentication mechanisms. Common Directory Schema A directory schema defines the rules by which objects are stored and retrieved in the directory. A common schema allows different applications to share the same set of objects (user, printer, etc.) such that the information for a person or resource is not created and stored in multiple places within the network. In addition, a common schema definition allows directory-enabled applications to be developed independent of a specific directory implementation. Meta directory To ensure interopretability with non-LDAP based directory and synchronization of their contents, a set of meta directory functions is defined. The meta directory serves two purposes: it is used as the "master" for directory information by all other directories and it synchronizes the information between the different directories in an organization, allowing users accessing any of the directories to see the same information. The meta directory provides the basis for common administration of the information stored in the directory by different applications, such as configuration and security data.
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 computingbased 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 perapplication basis. Industry standards which influence the framework's schema include:
!
!
!
IETF (http://www.ietf.org) There are several RFCs that define schema for LDAP v2 and LDAP v3 derived from industry experience and X.500 standards. [See section IETF RFCs below for details.] Network Application Consortium's (http://www.netapps.org) Lightweight Internet Person Schema (LIPS) LIPS is an industry consensus for the definition of a person object. It includes information pertaining to white pages, organization, residence, phone numbers, IDs and passwords, etc. This schema has also been adopted by the Open Group and specified in the Internet White Pages profile (a profile that directory servers may support). Desktop Management Task Force (http://www.dmtf.org) Common Information Model (CIM) CIM defines schema for managed elements in a system. These consist of physical objects such as computer systems, software objects, devices, etc. The Directory Enabled Network (DEN) schema is incorporated by CIM.
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:
! !
!
Population of the master directory from existing (slave) directories When an object is added to one of the slave directories, a synchronization function propagates the object's information to the master directory. This is an event-driven synchronization function, which is activated when an event such as object add, update or delete occurs. When an object is added to the master directory or when an update that occurs in a slave directory is propagated to the master directory, a filtering down synchronization function propagates the information to slave directories. This can be configured as event-driven or scheduled synchronization. If configured as event-driven, this function will be invoked when an event such as object add, update or delete occurs. Scheduled synchronization will occur at pre-specified intervals. Authorization checks are performed at the master directory and, potentially, at slave directories before applying the updates.
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.
!
!
LDAP Version 2: ! RFC 1777: Defines the LDAP protocol ! RFC 1778: The String Representation of Standard Attribute Syntax's ! RFC 1779: A String Representation of Distinguished Names ! RFC 1959: An LDAP URL Format ! RFC 1960: A String Representation of LDAP Search Filters LDAP Version 3: ! RFC 2251: LDAP protocol - V3 ! RFC 2252: Lightwight Directory Access Protocol (v3): Attribute Syntax Definitions.
!
! ! !
RFC 2253: Lightwight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. RFC 2254: The String Representation of LDAP Search Filters. RFC 2255: The LDAP URL Format. RFC 2256: A Summary of the X.500 (96) User Schema for use with LDAPv3.