207 lines
12 KiB
HTML
207 lines
12 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>Directory Server (LDAP) - Directories</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="rzahydefdir"></a>
|
||
|
|
<h2 id="rzahydefdir">Directories</h2>
|
||
|
|
<p>The Directory Server allows access to a type of database that stores information
|
||
|
|
in a hierarchical structure similar to the way that the i5/OS integrated file
|
||
|
|
system is organized.</p>
|
||
|
|
<p>If the name of an object is known, its characteristics can be retrieved.
|
||
|
|
If the name of a particular individual object is not known, the directory
|
||
|
|
can be searched for a list of objects that meet a certain requirement. Directories
|
||
|
|
can usually be searched by specific criteria, not just by a predefined set
|
||
|
|
of categories.</p>
|
||
|
|
<p>A directory is a specialized database that has characteristics that set
|
||
|
|
it apart from general purpose relational databases. A characteristic of a
|
||
|
|
directory is that it is accessed (read or searched) much more often than it
|
||
|
|
is updated (written). Because directories must be able to support high volumes
|
||
|
|
of read requests, they are typically optimized for read access. Because directories
|
||
|
|
are not intended to provide as many functions as general-purpose databases,
|
||
|
|
they can be optimized to economically provide more applications with rapid
|
||
|
|
access to directory data in large distributed environments.</p>
|
||
|
|
<p>A directory can be centralized or distributed. If a directory is centralized,
|
||
|
|
there is one directory server (or a server cluster) at one location that provides
|
||
|
|
access to the directory. If the directory is distributed, there are multiple
|
||
|
|
servers, usually geographically dispersed, that provide access to the directory.</p>
|
||
|
|
<p>When a directory is distributed, the information stored in the directory
|
||
|
|
can be partitioned or replicated. When information is partitioned, each directory
|
||
|
|
server stores a unique and non-overlapping subset of the information. That
|
||
|
|
is, each directory entry is stored by one and only one server. The technique
|
||
|
|
to partition the directory is to use LDAP referrals. LDAP referrals allow
|
||
|
|
the users to refer Lightweight Directory Access Protocol (LDAP) requests to
|
||
|
|
either the same or different name spaces stored in a different (or same) server.
|
||
|
|
When information is replicated, the same directory entry is stored by more
|
||
|
|
than one server. In a distributed directory, some information can be partitioned
|
||
|
|
and some information can be replicated.</p>
|
||
|
|
<p>The LDAP directory server model is based on entries (which are also referred
|
||
|
|
to as objects). Each entry consists of one or more attributes, such as a name
|
||
|
|
or address, and a type. The types typically consist of mnemonic strings, such
|
||
|
|
as cn for common name or mail for e-mail address.</p>
|
||
|
|
<p>The example directory in <a href="rzahydefdir.htm#dirtree">Figure 1</a> shows an entry for Tim
|
||
|
|
Jones that includes mail and telephoneNumber attributes. Some other possible
|
||
|
|
attributes include fax, title, sn (for surname), and jpegPhoto.</p>
|
||
|
|
<p>Each directory has a schema, which is a set of rules that determine the
|
||
|
|
structure and contents of the directory. You can view the schema using the
|
||
|
|
Web administration tool. For more information about the schema, see <a href="rzahyschema.htm#rzahyschema">Schema</a>.</p>
|
||
|
|
<p>Each directory entry has a special attribute called objectClass. This attribute
|
||
|
|
controls which attributes are required and allowed in an entry. In other words,
|
||
|
|
the values of the objectClass attribute determine the schema rules the entry
|
||
|
|
must obey.</p>
|
||
|
|
<p>In addition to the attributes defined by the schema, entries also have
|
||
|
|
a set of attributes that are maintained by the server. These attributes,
|
||
|
|
known as operational attributes, include such things as when the entry was
|
||
|
|
created and access control information. For more information about operational
|
||
|
|
attributes, see <a href="rzahyoperational.htm#rzahyoperational">Operational attributes</a>.</p>
|
||
|
|
<p>Traditionally, LDAP directory entries are arranged in a hierarchical structure
|
||
|
|
that reflects political, geographic, or organizational boundaries (see <a href="rzahydefdir.htm#dirtree">Figure 1</a>). Entries that represent countries or regions appear at the
|
||
|
|
top of the hierarchy. Entries representing states or national organizations
|
||
|
|
occupy the second level down in the hierarchy. The entries below that can
|
||
|
|
then represent people, organizational units, printers, documents, or other
|
||
|
|
items.</p>
|
||
|
|
<p>LDAP refers to entries with Distinguished Names (DNs). Distinguished names
|
||
|
|
consist of the name of the entry itself as well as the names, in order from
|
||
|
|
bottom to top, of the objects above it in the directory. For example, the
|
||
|
|
complete DN for the entry in the bottom left corner of <a href="rzahydefdir.htm#dirtree">Figure 1</a> is
|
||
|
|
cn=Tim Jones, o=IBM, c=US. Each entry has at least one attribute that is used
|
||
|
|
to name the entry. This naming attribute is called the Relative Distinguished
|
||
|
|
Name (RDN) of the entry. The entry above a given RDN is called its parent
|
||
|
|
Distinguished Name. In the example above, cn=Tim Jones names the entry, so
|
||
|
|
it is the RDN. o=IBM, c=US is the parent DN for cn=Tim Jones. For more information
|
||
|
|
about DNs, see <a href="rzahyunderdn.htm#rzahyunderdn">Distinguished names (DNs)</a>.</p>
|
||
|
|
<p>To give an LDAP server the capability to manage part of an LDAP directory,
|
||
|
|
you specify the highest level parent distinguished names in the configuration
|
||
|
|
of the server. These distinguished names are called suffixes. The server can
|
||
|
|
access all objects in the directory that are below the specified suffix in
|
||
|
|
the directory hierarchy. For example, if an LDAP server contained the directory
|
||
|
|
shown in <a href="rzahydefdir.htm#dirtree">Figure 1</a>, it would need to have the suffix o=ibm, c=us
|
||
|
|
specified in its configuration in order to be able to answer client queries
|
||
|
|
regarding Tim Jones.</p>
|
||
|
|
<a name="dirtree"></a>
|
||
|
|
<div class="fignone" id="dirtree"><span class="figcap">Figure 1. LDAP directory structure</span>
|
||
|
|
<div class="mmobj">
|
||
|
|
<img src="rv4q100.gif" alt="An example of an LDAP directory structure" /></div></div>
|
||
|
|
<p>You are not limited to the traditional hierarchy when structuring your
|
||
|
|
directory. The domain component structure, for example, is gaining popularity.
|
||
|
|
With this structure, entries are composed of the parts of TCP/IP domain names.
|
||
|
|
For example, dc=ibm,dc=com might be preferable to o=ibm,c=us.</p>
|
||
|
|
<p>Say that you want to create a directory using the domain component structure
|
||
|
|
that will contain employee data such as names, telephone numbers, and email
|
||
|
|
addresses. You use the suffix or naming context based on the TCP/IP domain.
|
||
|
|
This directory might be visualized as something similar to the following:</p>
|
||
|
|
<pre class="xmp">/
|
||
|
|
|
|
||
|
|
+- ibm.com
|
||
|
|
|
|
||
|
|
+- employees
|
||
|
|
|
|
||
|
|
+- Tim Jones
|
||
|
|
| 555-555-1234
|
||
|
|
| tjones@ibm.com
|
||
|
|
|
|
||
|
|
+- John Smith
|
||
|
|
555-555-1235
|
||
|
|
jsmith@ibm.com</pre>
|
||
|
|
<p>When entered in the Directory Server this data might actually look similar
|
||
|
|
to the following:</p>
|
||
|
|
<pre class="xmp"># suffix ibm.com
|
||
|
|
dn: dc=ibm,dc=com
|
||
|
|
objectclass: top
|
||
|
|
objectclass: domain
|
||
|
|
dc: ibm
|
||
|
|
|
||
|
|
# employees directory
|
||
|
|
dn: cn=employees,dc=ibm,dc=com
|
||
|
|
objectclass: top
|
||
|
|
objectclass: container
|
||
|
|
cn: employees
|
||
|
|
|
||
|
|
# employee Tim Jones
|
||
|
|
dn: cn=Tim Jones,cn=employees,dc=ibm,dc=com
|
||
|
|
objectclass: top
|
||
|
|
objectclass: person
|
||
|
|
objectclass: organizationalPerson
|
||
|
|
objectclass: inetOrgPerson
|
||
|
|
objectclass: publisher
|
||
|
|
objectclass: ePerson
|
||
|
|
cn: Tim Jones
|
||
|
|
cn: "Jones, Tim"
|
||
|
|
sn: Jones
|
||
|
|
givenname: Tim
|
||
|
|
telephonenumber: 555-555-1234
|
||
|
|
mail: tjones@ibm.com
|
||
|
|
|
||
|
|
# employee John Smith
|
||
|
|
dn: cn=John Smith,cn=employees,dc=ibm,dc=com
|
||
|
|
objectclass: top
|
||
|
|
objectclass: person
|
||
|
|
objectclass: organizationalPerson
|
||
|
|
objectclass: inetOrgPerson
|
||
|
|
objectclass: publisher
|
||
|
|
objectclass: ePerson
|
||
|
|
cn: John Smith
|
||
|
|
cn: "Smith, John"
|
||
|
|
sn: Smith
|
||
|
|
givenname: John
|
||
|
|
telephonenumber: 555-555-1235
|
||
|
|
mail: jsmith@ibm.com
|
||
|
|
</pre>
|
||
|
|
<p>You will notice that the each entry contains attribute values called objectclass.
|
||
|
|
The objectclass values define what attributes are allowed in the entry, such
|
||
|
|
as telephonenumber or givenname. The allowed object classes are defined in
|
||
|
|
the schema. The schema is a set of rules that defines the type of entries
|
||
|
|
allowed in the database.</p>
|
||
|
|
<p><span class="bold">Directory clients and servers</span></p>
|
||
|
|
<p>Directories are usually accessed using the client-server model of communication.
|
||
|
|
The client and server processes might or might not be on the same machine.
|
||
|
|
A server is capable of serving many clients. An application that wants to
|
||
|
|
read or write information in a directory does not access the directory directly.
|
||
|
|
Instead, it calls a function or application programming interface (API) that
|
||
|
|
causes a message to be sent to another process. This second process accesses
|
||
|
|
the information in the directory on behalf of the requesting application.
|
||
|
|
The results of the read or write are then returned to the requesting application.</p>
|
||
|
|
<p>An API defines the programming interface a particular programming language
|
||
|
|
uses to access a service. The format and contents of the messages exchanged
|
||
|
|
between client and server must adhere to an agreed on protocol. LDAP defines
|
||
|
|
a message protocol used by directory clients and directory servers. There
|
||
|
|
is also an associated LDAP API for the C language and ways to access the directory
|
||
|
|
from a Java application using the Java Naming and Directory Interface (JNDI).</p>
|
||
|
|
<p><span class="bold">Directory security</span></p>
|
||
|
|
<p>A directory should support the basic capabilities needed to implement a
|
||
|
|
security policy. The directory might not directly provide the underlying security
|
||
|
|
capabilities, but it might be integrated with a trusted network security service
|
||
|
|
that provides the basic security services. First, a method is needed to authenticate
|
||
|
|
users. Authentication verifies that users are who they say they are. A user
|
||
|
|
name and password is a basic authentication scheme. Once users are authenticated,
|
||
|
|
it must be determined if they have the authorization or permission to perform
|
||
|
|
the requested operation on the specific object.</p>
|
||
|
|
<p>Authorization is often based on access control lists (ACLs). An ACL is
|
||
|
|
a list of authorizations that might be attached to objects and attributes
|
||
|
|
in the directory. An ACL lists what type of access each user or a group of
|
||
|
|
users is allowed or denied. In order to make ACLs shorter and more manageable,
|
||
|
|
users with the same access rights are often put into groups.</p>
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|