Directory service

Article on other languages:

del.icio.us del.icio.us
Digg Digg
Furl Furl
Reddit Reddit
Rojo Rojo
Add to OnlyWire

In software engineering, a directory is similar to a dictionary; it enables the look up of a name and information associated with that name. As a word in a dictionary may have multiple definitions, in a directory, a name may be associated with multiple, different, pieces of information. Likewise, as a word may have different parts and different definitions, a name in a directory may have many different types of data. Based on this rudimentary explanation of a directory, a directory service is simply the software system that stores, organizes and provides access to information in a directory.

Directories may be very narrow in scope, supporting only a small set of node types and data types, or they may be very broad, supporting an arbitrary or extensible set of types. In a telephone directory, the nodes are names and the data items are telephone numbers. In the DNS the nodes are domain names or internet addresses. In a directory used by a network operating system, the nodes represent resources that are managed by the OS, including users, computers, printers and other shared resources. Many different directory services have been used since the advent of the Internet but this article focuses mainly on those that have descended from the X.500 directory service.

Contents

Introduction

A simple directory service called a naming service maps the names of network resources to their respective network addresses. With the name service type of directory, a user doesn't have to remember the physical address of a network resource; providing a name will locate the resource. Each resource on the network is considered an object on the directory server. Information about a particular resource is stored as attributes of that object. Information within objects can be made secure so that only users with the available permissions are able to access it. More sophisticated directories are designed with namespaces as Subscribers, Services, Devices, Entitlements, Preferences, Content and so on. This design process is highly related to Identity management.

A directory service defines the namespace for the network. A namespace in this context is the term that is used to hold one or more objects as named entries. The directory design process normally has a set of rules that determine how network resources are named and identified. The rules specify that the names be unique and unambiguous. In X.500 (the directory service standards) and LDAP the name is called the distinguished name (DN) and is used to refer to a collection of attributes (relative distinguished names) which make up the name of a directory entry.

A directory service is a shared information infrastructure for locating, managing, administering, and organizing common items and network resources, which can include volumes, folders, files, printers, users, groups, devices, telephone numbers and other objects. A directory service is an important component of a NOS (Network Operating System). In the more complex cases a directory service is the central information repository for a Service Delivery Platform. For example, looking up "computers" using a directory service might yield a list of available computers and information for accessing them.

Replication and Distribution have very distinct meanings in the design and management of a directory service. The term replication is used to indicate that the same directory namespace (the same objects) are copied to another directory server for redundancy and throughput reasons. The replicated namespace is governed by the same authority. The term distribution is used to indicate that multiple directory servers, that hold different namespaces, are interconnected to form a distributed directory service. Each distinct namespace can be governed by different authorities.

Comparison with relational databases

There are a number of things that distinguish a traditional directory service from a typical relational database. Of course there are exceptions, but in general:

  • directory information is read more often than it is written, this makes features related to transactions and rollback less important.
  • data can be redundant if it helps performance.
  • because modeling data in a strictly hierarchical manner can be difficult and expensive for processing, some directories will first look for items based on their data attributes and then filter the results for the correct structure.
  • traditional directories do not have many-to-many relations, so these are maintained using lists of distinguished names or other identifiers. This is similar to the cross table identifiers used in relational databases.
  • Originally X.500-type hierarchies were considered problematic compared to relational data designs. However the hierarchical object models in modern, Java-based, object-oriented databases and XML document forms indicates that directories are evolving away from traditional relational databases.

Directory schemas are defined as object classes, attributes, name bindings and knowledge (namespaces), where an objectClass has:

  • Must - attributes that each of its instances must have
  • May - attributes that can be defined for an instance, but can be omitted with the absence treated somewhat like NULL in a relational databases
  • Attributes are sometimes multi-valued allowing multiple naming attributes at one level such as machine type and serial number concatenated or multiple phone numbers for "work phone".
  • Attributes and objectClasses are standardized throughout the industry and formally registered with the IANA for their object ID. Therefore directory applications seek to reuse much of the standard classes and attributes to maximize the benefit of existing directory server software.
  • Object instances are slotted into namespaces. That is, each objectClass inherits from its parent objectClass (and ultimately from the root of the hierarchy) adding attributes to the must/may list.
  • Directory services are often a central component in the security design of an IT system and have a correspondingly fine granularity regarding access control: who may operate in which manner on what information. Also see: ACLs

Architecturally, a major difference is that a database-centric applications is designed to use a specific, dedicated (relational), data model, but a directory is used to hold "identified" objects that for use by many applications in random ways. A Directory service is applied where "multi governance" (many applications and users) are, for integrity and efficiency reasons, using the same information. Common directory data sets are user accounts, address books, rosters, preferences, entitlements, products and services, devices, profiles, policies, telephone numbers, routing information, etc.

For obvious reasons, this makes directory design quite different from relational database design. Relational data models tend to optimize for specific business and process requirements leaving issues such as personalization, presence, performance or scaling to be handled elsewhere in the system. However the priorities for the data model are to be usable with minimal explanation, and that the design scales.

An obvious indication of this Indicative of this of relational database designs are the large number of them for different processes. and are now trying to converge their user and service identity information and their online goods and services management, and deliver these in real time, cost effectively. So a large scale directory service should be in their solution architecture.

Implementations of directory services

Directory services were part of an Open Systems Interconnection (OSI) initiative to get everyone in the industry to agree to common network standards to provide multi-vendor interoperability. In the 1980s the ITU and ISO came up with a set of standards - X.500, for directory services, initially to support the requirements of inter-carrier electronic messaging and network name lookup. The Lightweight Directory Access Protocol, LDAP, is based on the directory information services of X.500, but uses the TCP/IP stack and a string encoding scheme of the X.500 protocol DAP, giving it more relevance on the Internet.

There have been numerous forms of directory service implementations from different vendors. Systems developed before the advent of X.500 include:

Among the LDAP/X.500 based implementations are:

  • eDirectory: This is Novell's implementation of directory services. It supports multiple architectures including Windows, NetWare, Linux and several flavours of Unix and has long been used for user administration, configuration management, and software management. eDirectory has evolved into a central component in a broader range of Identity management products. It was previously known as Novell Directory Services.
  • Red Hat Directory Server: Red Hat released a directory service, that it acquired from AOL's Netscape Security Solutions unit[1], as a commercial product running on top of Red Hat Enterprise Linux called Red Hat Directory Server and as part of Fedora Core called Fedora Directory Server.
  • Active Directory: Microsoft's directory service is the Active Directory which is included in the Windows 2000 and Windows Server 2003 operating system versions.
  • Open Directory: Apple's Mac OS X Server offers a directory service called Open Directory which integrates with many open standard protocols such as LDAP and Kerberos as well as proprietary directory solutions like Active Directory and eDirectory. It is a customized build of OpenLDAP.
  • Apache Directory Server: Apache Software Foundation offers a directory service called ApacheDS.
  • Oracle Internet Directory: (OID) is Oracle Corporation's directory service, which is compatible with LDAP version 3.
  • CA Directory: CA Directory contains pre-caching engine which can index all attributes that are used in LDAP search filters, and caching all attributes returned in search results.
  • Sun Java System Directory Server: Sun Microsystems' current directory service offering, found at [2].
  • OpenDS: An open source directory service implementation from scratch in Java, backed by Sun Microsystems and hosted at [3].
  • Banyan VINES: - The first scalable directory services offering.
  • IBM Tivoli Directory Server It is a customized build of an old release of OpenLDAP.
  • Siemens DirX Directory Server
  • Windows NT Directory Services (NTDS)
  • Critical Path Directory Server
  • OpenLDAP Derived from the original University of Michigan reference LDAP implementation (as are the Netscape/Red Hat/Fedora/Sun JSDS servers) but significantly evolved. It supports all current computer architectures, including Unix and Unix derivatives, Linux, Windows, z/OS, and a variety of embedded/realtime systems.
  • Isode Limited: High performance and high availability LDAP and X.500 servers.

There are also plenty of open-source tools to create directory services, including OpenLDAP and the Kerberos protocol, and Samba software which can act as a Windows Domain Controller with Kerberos and LDAP backends.

Notes

See also

References

External links

  • Directory Technology Review - An investigation into the use of directories for developing a management application which can manage both data and network services, specifically for the web hosting industry.
  • EngNet Engineering Directory Online Directory categorized by products and services within engineering and industry disciplines
Retrieved from "http://en.wikipedia.org/wiki/Directory_service"

This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License.

Giant Panda

Mercedes Car
James Bond Guide
This site monitored by SitePinger.net