The key components of the ISODE Consortium's Directory Services are an X.500 1993 Directory System Agent (DSA), DUAs, configuration and management tools, programming interfaces and supporting tools and interfaces.
With the introduction of the 1993 DSA, the distribution and support of QUIPU will begin to be phased out. It has been included in this release for backward compatibility purposes but will be retired prior to IC R4.0.
IC R3.0 introduces an X.500 1993 Directory System Agent (DSA). It has been designed and implemented as an X.500 1993 DSA; not as a 1988 DSA with `93 extensions. Emphasis has been placed on providing support for a flexible information model, support for access control, X.509 security features, and replication.
The 1993 DSA offers a strong technical foundation on which to build an information and messaging infrastructure that relies on robust and scalable directory services. The implementation of the DSA incorporates the experience gained through the development, support, and maintenance of QUIPU as well as operational experience and standards support.
The major design features of the 1993 DSA include a multi-threaded object-oriented protocol engine and operations management dispatcher, a dynamic object-oriented information tree representing configurable knowledge of directory information, and user extensible object-oriented Generic Directory API (GDA) providing a modular interface to protocol and back-end database services or non-X.500 directory services.
The following diagram depicts the key functional components of the DSA and their interrelationship.
At the core of the 1993 DSA is a flexible and extensible object-oriented framework that allows incremental addition of critical 1993 features as the product evolves. This framework represents a departure from the internal architecture of the IC's 1988 QUIPU DSA, while maintaining those QUIPU DSA features that are useful.
A multi-threaded object-oriented protocol engine is provided with association management and operations management implemented as a collection of interacting, concurrent objects thus providing more structured and manageable code.
- Support of multiple databases
The structure and data that provides the knowledge of directory information are encapsulated in a run-time information tree that is built by the DSA at start-up and is used to process and progress operation requests. This information tree also serves to map operations onto appropriate modules that map onto one or more database back-end technologies where the directory information is actually stored.
Functionality and code from the QUIPU DSA has been reused allowing the 1993 DSA to build upon QUIPU's superior functionality. Existing QUIPU C code is reused by encapsulating the functionality within an object-oriented interface.
The 1993 DSA architecture supports the 1993 extensions to the Directory Protocols and the 1993 features of replication, access control, the X.509 authentication framework, and the new Information Model.
- Modularity and Extensibility
The functionality required by a 1993 DSA is complex. This complexity dictates a modular approach that allows reuse of existing code and ease of extension to incorporate new functionality.
- Ease of Management and Configuration
The DSA is easy to configure and manage. Minimal configuration information is required on start-up and additional configuration information is obtained dynamically. Once the DSA is initialized, its operation is configurable using flexible management tools.
The DSA meets the operational needs of a commercial organization. Multi-threading of the protocol engine and operation dispatching functions facilitates the performance of the DSA servers and allows the 1993 DSA performance to exceed that of QUIPU.
A code framework containing a high degree of modularity and abstraction provides the ISODE Consortium customers with an extensible and maintainable base on which to base value-added features.
- Deployment and Scalability
To meet a variety of information services as part of an enterprise-wide information infrastructure, the DSA provides support for ease of deployment and the ability to scale the directory services to the size of the operational environment. It is architected in a manner that lends itself to access from non-X.500 client applications either directly or through appropriate gateways such as a World-Wide Web to X.500 gateway.
The functionality of the 1993 DSA will be introduced in R3.0 followed by incremental releases planned through 1996 to extend existing functionality and add new functionality. This functionality includes:
Support of all Directory Access Protocol (DAP) operations defined in the 1993 X.519 standard. DAP is the OSI application layer protocol used to communicate between a user of the Directory and a DSA. It realizes the Directory Abstract Service defined in X.511.
Support of all Directory System Protocol (DSP) operations defined in the 1993 X.519 standard. DAP is the OSI application layer protocol used to communicate between DSAs which are co-operating to provide a distributed Directory. It is the realization of the DSA Abstract Service defined in X.518.
Schema support of all attribute types and object classes as defined in X.520 (1993) and X.521 (1993) as well as those defined in RFC 1274 (The COSINE and Internet X.500 Schema).
Support of the BIND operation using no credentials, simple credentials, and strong credentials as defined in the 1993 standard.
Support of a subset of 1993-defined Basic Access Control.
Storage of the Directory Information Tree (DIT) as files in a disk-based database using vendor-supplied hash databases to store and access the DIT directly on disk.
Replication using 93 DISP including support for primary and secondary shadowing, incremental and full updates, supplier initiated updates, and on-change updates.
- Directory Abstract Service
Provision of the Directory Abstract Service in a distributed environment as defined in X.518 (1993) including support of chaining and referral modes of operation, superior references, and subordinate references.
Configuration of the DSA via DAP using standard knowledge references.
Multiple access protocols and databases are integrated using the Generic Directory API (GDA). The GDA aims to provide improved performance, simpler management, and better security.
Some of the existing QUIPU code, in particular some protocol and disk based database components, are re-used in the DSA. The QUIPU-centric view of the world is replaced with an internal structure that uses an internal information model that is based on the 1993 information model and subschema.
A feature of the 1993 DSA is the ability to easily integrate additional protocols and databases. This is achieved by modelling the DSA as a number of object-oriented components, each of which provides some portion of the directory abstract services.
The core of the DSA is implemented as a modular and extensible object-oriented framework written primarily in C++, with some functionality written in C, but wrapped by C++ abstractions.
- Single Process, Multiple Threads
Due to the nature of database servers, the 1993 DSA is implemented (like QUIPU) as a single responder (daemon) process. Threads are used to provide a mechanism for managing multiple associations and concurrent directory operations. Thread management is concentrated in the operations manager.
- Directory Service Access Point
A Directory Service Access Point (DSAP) abstraction encapsulates the protocol stack using a mutual exclusion layer that serializes threads competing for access to the stack.
A generic I/O event management function deals with low-level network events and the establishment of new associations in response to bind requests. The DSAP abstraction is used to build individual protocol directory contexts: DAP initiator and responder contexts, DSP initiator and responder contexts, and DISP contexts. Each DSAP context corresponds to an association binding over ROSE, from which operations are received and sent. The protocol stack and the DSAP contexts collectively represent the DSA protocol engine. This engine operates concurrently and is capable of managing simultaneous associations. Operation requests or responses appearing on a particular DSAP context for an association are decoded, authenticated, and eventually handed over to the operations dispatching mechanism as a new thread of control.
DAP, DSP, and DISP are implemented by means of separate protocol modules that are derived from a generic DSAP protocol module layered on top of ROSE.
The DISP module provides support for replication by the DSA. Support is provided for primary and secondary shadowing, incremental and full updates, supplier initiated updates, and on-change updates.
Central to the DSA is a multi-threaded operation management core that initiates new operations, monitors their progress, and deals with operations chaining and returning of results and/or referrals. Operations are dispatched as threads in response to operation requests coming from the protocol engine.
The operation management component uses an abstract GDA to isolate itself from the particular details of either a protocol-based service or a back-end database. The GDA abstraction is used on the database side of the operations dispatcher to encapsulate database specific access procedures so that new database technologies can be added in as the DSA is scaled to handle additional information.
Multi-threading in the DSA requires support for a basic POSIX threads capability. Threads are restricted to pseudo-concurrency on a uni-processor and scale to true concurrency on SMP architectures. An object-oriented thread abstraction is provided in the DSA that maps onto a POSIX threads interface, provided either by an operating system threads library (e.g., Solaris threads) or by some other threads interface with architecture specific context switching code. The thread abstraction guarantees serialized access to libraries that are not thread safe. The object-oriented threads model may be mapped onto kernel supported C thread libraries or other Pthreads packages. The ISODE Consortium release provides a user space minimal POSIX C threads package that offers a multi-platform threads capability on a variety of standard uni-process architectures.
The DSA supports the procedures for provision of the Directory Abstract Service in a distributed environment as defined in X.518. It supports the chaining and referral modes of operation, with chaining preferred except where prohibited by service controls.
- Superior and Subordinate References
The DSA supports the standard superior references and subordinate references and is able to act as a first level DSA as defined in X.518.
The representation of knowledge in the directory is accomplished via a special purpose memory database that holds knowledge about the distribution of the DIT amongst DSAs globally, and databases locally.
The database maintains a tree structure of nodes representing entries in the DIT. Knowledge is represented as attributes of entries corresponding to the boundaries between naming contexts. This database is loaded from configuration information at DSA start-up.
The knowledge information tree used by the operations manager contains DSA Specific Entry (DSE) information used for name resolution, pre-filtering, access control checks, and operation progressing. The information tree knows about the configured GDA modules mapping onto database back-ends and is capable of routing operation requests to different database back-ends.
The 1993 DSA architecture specifically provides support for adding additional database back-ends by providing a database-independent GDA. As part of the 1993 DSA, a disk-based GDA module is supplied. This module stores a subtree of the DIT in a disk-based database, and implements all of the X.500 operations for entries within that subtree. A UNIX NDBM encapsulation layer is provided on top of a Berkeley DB hash library.
The GDA approach provides an extensible interface for adding additional database technologies to the back-end.
The 1993 DSA supports the BIND operation using no-credentials and simple credentials as defined in X.509 (1993).
DSAs providing the Directory service perform access control checks in order to determine what operations an authenticated user may perform on entries, attributes, and values. In X.500 (1988) these procedures were not specified, but X.500 (1993) includes a complete access control mechanism specification termed the Basic Access Control scheme (BAC), and a variation of it termed the Simplified Access Control scheme (SAC).
The ISODE Consortium Access Control scheme (IC-AC), a subset of Basic Access Control, is available.
IC-AC makes use of the same access control information syntax as BAC. This information may be placed in the entryACI operational attribute of entries to which it will apply. Although neither prescriptiveACI nor subentryACI attribute values are used, naming contexts mastered by an IC DSA using IC-AC may be shadowed correctly by a DSA which supports either IC-AC or BAC.
In BAC, a Directory Access Control Domain includes all entries which currently reside within or could be added to a specified subtree. In the initial release of IC-AC a DACD is limited to a single entry, and it is not possible to specify access control information for entries which do not exist: only the DSA manager is permitted to perform AddEntry and ModifyDN operations.
The Access Control decision function implemented is the same as that specified in X.501 (1993) and X.511 (1993), except that in IC R3.0:
- group and subtree membership checks are not performed,
- selfValue protected items are not used,
- unique identifiers are not compared.
The DSA Disk-based database also implements the PARADISE searchACL attribute, as X.501 (1993) Basic Access Control does not include a mechanism to protect against Directory trawling.
A mapping has been defined from the QUIPU access control attributes authPolicy, listACL, searchACL and acl into the Access Control Information Syntax attribute entryACI. The EDB conversion tool which produces the X.500 (93) DSA Directory Information Base performs this conversion automatically.
In order to verify the results of the conversion, management tools are provided to view the structure and contents of the entryACI attribute, and to simulate the access control decision function independently of the DSA.
Those elements which do not have an equivalent in IC-AC are not mapped.
QUIPU is an extensively deployed implementation of an X.500 DSA. The IC R3.0 release of QUIPU remains largely unchanged from IC R2 and provides the following features:
Support of all the DAP and DSP operations defined in the 1988 X.519 standard.
Schema support of all attribute types and object classes as defined in X.520 (1988) and X.521 (1988) as well as those defined in RFC 1274.
Support of the BIND operation using no credentials, simple credentials, or protected simple credentials, as defined in the 1988 X.509 standard.
Support of a proprietary access control mechanism consistent with the basic approach described in Annex F of the 1988 X.509 standard.
Storage of the DIT as files in the UNIX filestore which, at runtime, are loaded into an in-memory database.
Replication via extensions to the DSP as defined in RFC 1276 (Replication and Distribution Operations Extensions to Provide an Internet Directory using X.500).
Provision of the Directory Abstract Service in a distributed environment as defined in the 1988 X.518 standard including support of chaining and referral modes of operation, superior references, subordinate references, and cross-references, and to act as a first level DSA.
Support of a delegate DSA to hold a subtree of the DIT. This is contained in a disk-based database using vendor-supplied hash databases to store and access the DIT directly on disk.
Configuration of the DSA via a combination of runtime tailor files and attributes held in the DSA's own entry in the directory.
Monitoring via DAP.
A command line DUA and a graphical DUA are provided as part of this release.
The Directory Information Shell (DISH) is a command-line user agent with which Directory administrators and technically oriented users can manage and browse information in the DIB. It also has a mode of operation in which operations can be invoked directly from the UNIX shell, thus providing a useful scripting capability.
DISH supports all operations of the directory access application context defined in X.511 (1993), by means of commands which map directly to the operations.
All service controls defined in X.511 (1993) are supported by means of command switches which map directly to the controls.
Support is provided for binding to the directory with no credentials, with unprotected simple credentials (user name and password in the clear), or with protected simple credentials (password encrypted).
DISH uses the schema functionality provided by the DSAP library.
The X.500 Lookup Utility (Xlu) is a graphical user agent with which non-technical users can lookup up information in the Directory. It uses the X11 Window System for its user interface.
The XLU user interface is highly configurable. The appearance and function of windows is defined in a text file which specifies how the windows are constructed from built-in XLU primitives. A number of sample configurations are supplied, including a forms-based interface which mirrors the structure of the DIT, and a User Friendly Naming interface which hides it.
Rules can be defined which specify where to search for an entry based on how much of the name the user enters, and how to search for different classes of entry.
The manner in which entries are displayed can also be configured by specifying the attributes to be displayed, the labels to be used for them, and their layout.
XLU uses multiple complex Search operations to lookup an entry. It also supports the Read operation for displaying entries, the List operation for browsing, and the Modify operation for changing entries.
XLU uses the schema functionality provided by the DSAP library.
Configuration of the 1993 DSA is handled almost entirely by use of information stored in the directory. A small amount of information needed for bootstrap is passed as start-up parameters to the DSA.
DUA configuration parameters are controlled by a text tailor file.
- Tcl/Tk-based Configuration Tool
The first elements of an extensible Tcl/Tk based X-Windows Toolkit is being released, with substantial ongoing work planned in this area. This tool will allow for rapid development of customer defined user agents.
DSP and DAP connection status is monitored using Simple Network Management Protocol (SNMP) and the X.500 Directory Monitoring MIB (RFC 1567). This information may be accessed by use of a number of SNMP monitors. SNMP vendor independence is seen as a strength of this product with SNMP vendors supplying a wide range of interfaces.
An implementation of the X/Open API to Directory Services (XDS) provides a standard interface to the IC Directory Services. This API is described in the X/Open CAE Specification, API to Directory Services (XDS), Issue 2 available from the X/Open Company Limited.
- Lightweight Directory Access Protocol (LDAP)
The Lightweight Directory Access Protocol (LDAP), defined in RFC 1487, is a protocol used to communicate between a user of the Directory and a DSA without incurring the resource requirements of DAP. Protocol elements are carried directly over TCP or other transports, bypassing much of the overhead of the OSI upper layers.
LDAP is supported by means of a separate server process which translates LDAP requests into DAP requests, forwards them to a DSA over a dedicated DAP association set up for the client, and then converts the DAP response to an LDAP response which is sent back to the client.
The LDAP library implements an API which client applications use to access the directory via the Lightweight Directory Access Protocol. Because LDAP can be used directly over TCP, it is especially suitable for use in small client applications and on PCs, where the overhead of the full OSI stack may be unacceptable.
The API supports all the operations defined by the protocol in RFC 1487, via a set of asynchronous function calls.
- Directory Services Access Point (DSAP)
The Directory Service Access Point (DSAP) library implements an API which client applications, such as DUAs, use to access the directory. It also implements functionality which is required by both DUAs and DSAs, such as attribute type and object class definition, and attribute syntax handling.
The DSAP library implements a proprietary API which supports all of the operations of the Directory Abstract Service defined in X.511 (1988). The API is procedural in style, with a one-to-one mapping between API calls and the underlying abstract operations.
Both synchronous and asynchronous usage are supported, with the ability to issue multiple concurrent operations in asynchronous case.
The DSAP library supports the definition of attribute types and object classes. The definitions are stored in runtime tailor files and may be managed with a text editor. By default, all the attribute types and object classes defined in X.520 (1993) and X.521 (1993) are supported, as well as those defined in RFC 1274). New attribute types and object classes can be created by adding the appropriate definitions.
An attribute syntax is implemented as a set of routines for encoding, decoding, parsing, printing, and comparing the attribute values of that syntax. The DSAP library contains routines for the syntaxes of all of the attribute types described above. New syntaxes can be created by implementing the required syntax handling routines and linking them into the application. For example, the IC MTA contains a set of syntax handlers to support MHS use of the Directory.
The ability to integrate the ISODE Consortium's Directory Services with other technology is key to the ISODE Consortium's future technical strategy. As part of IC R3.0, a WWW-X.500 Gateway is being introduced as the first step of this strategy.
- World Wide Web to X.500 Gateway
A World Wide Web (WWW) to X.500 Gateway is provided and supports HTML-based DUA bindings using LDAP. This capability can be extended to support a management binding. This allows a user or integrator to customize the management interface as it is based on the extensible Hyper-Text Markup Language (HTML) used in popular WWW browser tools.