6480N/A<?
xml version="1.0" encoding="UTF-8"?>
6480N/A ! This work is licensed under the Creative Commons 6480N/A ! Attribution-NonCommercial-NoDerivs 3.0 Unported License. 6480N/A ! To view a copy of this license, visit 6480N/A ! or send a letter to Creative Commons, 444 Castro Street, 6480N/A ! Suite 900, Mountain View, California, 94041, USA. 6480N/A ! You can also obtain a copy of the license at 6480N/A ! See the License for the specific language governing permissions 6480N/A ! and limitations under the License. 6480N/A ! If applicable, add the following below this CCPL HEADER, with the fields 6480N/A ! enclosed by brackets "[]" replaced with your own identifying information: 6480N/A ! Portions Copyright [yyyy] [name of copyright owner] 7321N/A ! Copyright 2011-2015 ForgeRock AS. 6480N/A<
chapter xml:
id='chap-understanding-ldap' 6480N/A <
title>Understanding Directory Services</
title>
6480N/A <
primary>Directory services</
primary>
6480N/A <
secondary>About</
secondary>
6480N/A <
secondary>About</
secondary>
6480N/A <
para>A directory resembles a dictionary or a phone book. If you know a
6480N/A word, you can look it up its entry in the dictionary to learn its definition
6480N/A or its pronunciation. If you know a name, you can look it up its entry in the
6480N/A phone book to find the telephone number and street address associated with the
6480N/A name. If you are bored, curious, or have lots of time, you can also read
6480N/A through the dictionary, phone book, or directory, entry after entry.</
para>
6480N/A <
para>Where a directory differs from a paper dictionary or phone book is
6480N/A in how entries are indexed. Dictionaries typically have one index: words
6480N/A in alphabetical order. Phone books, too: names in alphabetical order.
6480N/A Directories entries on the other hand are often indexed for multiple
6480N/A attributes, names, user identifiers, email addresses, telephone numbers.
6480N/A This means you can look up a directory entry by the name of the user the
6480N/A entry belongs to, but also by her user identifier, her email address, or
6480N/A her telephone number, for example.</
para>
6480N/A <
para>OpenDJ directory services are based on the Lightweight Directory Access
6480N/A Protocol (LDAP). Much of this chapter serves therefore as an introduction to
6480N/A LDAP. OpenDJ directory services also provide RESTful access to directory data,
6480N/A yet as directory administrator you will find it useful to understand the
6480N/A underlying model even if most users are accessing the directory over HTTP
6480N/A <
section xml:
id="ldap-directory-history">
6480N/A <
title>How Directories & LDAP Evolved</
title>
6480N/A <
para>Phone companies have been managing directories for many decades. The
6480N/A Internet itself has relied on distributed directory services like DNS since
6480N/A <
para>It was not until the late 1980s, however, that experts from what is now
6480N/A the International Telecommunications Union brought forth the X.500 set of
6480N/A international standards, including Directory Access Protocol. The X.500
6480N/A standards specify Open Systems Interconnect (OSI) protocols and
6480N/A data definitions for general-purpose directory services. The X.500 standards
6480N/A were designed to meet the needs of systems built according to the X.400
6480N/A standards, covering electronic mail services.</
para>
6480N/A <
para>Lightweight Directory Access Protocol has been around since the early
6480N/A 1990s. LDAP was originally developed as an alternative protocol that would
6480N/A allow directory access over Internet protocols rather than OSI protocols,
6480N/A and be lightweight enough for desktop implementations. By the mid 1990s, LDAP
6480N/A directory servers became generally available and widely used.</
para>
6480N/A <
para>Until the late 1990s, LDAP directory servers were designed primarily
6480N/A with quick lookups and high availability for lookups in mind. LDAP directory
6480N/A servers replicate data, so when an update is made, that update gets pushed
6480N/A out to other peer directory servers. Thus if one directory server goes down,
6480N/A lookups can continue on other servers. Furthermore, if a directory service
6480N/A needs to support more lookups, the administrator can simply add another
6480N/A directory server to replicate with its peers.</
para>
6480N/A <
para>As organizations rolled out larger and larger directories serving more
6480N/A and more applications, they discovered that they needed high availability
6480N/A not only for lookups, but also for updates. Around the year 2000 directories
6480N/A began to support multi-master replication, that is replication with multiple
6480N/A read-write servers. Soon thereafter the organizations with the very largest
6480N/A directories started to need higher update performance as well as
6480N/A <
para>The OpenDJ code base began in the mid 2000s, when engineers solving the
6480N/A update performance issue decided the cost of adapting the existing C-based
6480N/A directory technology for high performance updates would be higher than the
6480N/A cost of building a next generation, high performance directory using Java
6480N/A <
section xml:
id="directory-data">
6480N/A <
title>About Data In LDAP Directories</
title>
6480N/A <
secondary>Data</
secondary>
6480N/A <
para>LDAP directory data is organized into entries, similar to the entries
6480N/A for words in the dictionary, or for subscriber names in the phone book.
6480N/A A sample entry follows.</
para>
7288N/A <
programlisting language="ldif">
7097N/Adn: uid=bjensen,ou=People,dc=example,dc=com
6480N/AfacsimileTelephoneNumber: +1 408 555 1992
6480N/AobjectClass: organizationalPerson
6480N/AtelephoneNumber: +1 408 555 1862
6480N/A <
para>Barbara Jensen's entry has a number of attributes, such as
6480N/A <
literal>uid: bjensen</
literal>,
6480N/A <
literal>telephoneNumber: +1 408 555 1862</
literal>, and
6480N/A <
literal>objectClass: posixAccount</
literal><
footnote><
para>The
6480N/A <
literal>objectClass</
literal> attribute type indicates which types of
6480N/A attributes are allowed and optional for the entry. As the entries object
6480N/A classes can be updated online, and even the definitions of object classes
6480N/A and attributes are expressed as entries that can be updated online, directory
6480N/A data is extensible on the fly.</
para></
footnote>. When you look up her entry
6480N/A in the directory, you specify one or more attributes and values to match.
6480N/A The directory server then returns entries with attribute values that match
6480N/A <
para>The attributes you search for are indexed in the directory, so the
6480N/A directory server can retrieve them more quickly.<
footnote><
para>Attribute
6480N/A values do not have to be strings. Some attribute values are pure binary like
6480N/A certificates and photos.</
para></
footnote></
para>
6480N/A <
para>The entry also has a unique identifier, shown at the top of the entry,
6480N/A <
literal>dn: uid=bjensen,ou=People,dc=example,dc=com</
literal>. DN stands
6480N/A for distinguished name. No two entries in the directory have the same
6480N/A distinguished name. Yet, DNs are typically composed of case insensitive
6480N/A attributes.<
footnote><
para>Sometimes your distinguished names include
6480N/A characters that you must escape. The following example shows an entry that
6480N/A includes escaped characters in the DN.</
para>
7097N/A$ <
userinput>ldapsearch --port 1389 --baseDN dc=example,dc=com "(uid=escape)"</
userinput>
7097N/A<
computeroutput>dn: cn=\" # \+ \, \; \< = \> \\ DN Escape Characters,dc=example,dc=com
6480N/AobjectClass: organizationalPerson
6480N/AgivenName: " # + , ; < = > \
6480N/Acn: " # + , ; < = > \ DN Escape Characters
7097N/Amail: escape@example.com</
computeroutput>
7097N/A </
screen></
footnote></
para>
6480N/A <
para>LDAP entries are arranged hierarchically in the directory. The
6480N/A hierarchical organization resembles a file system on a PC or a web server,
6480N/A often imagined as an upside-down tree structure, looking similar to a
6480N/A pyramid. <
footnote><
para>Hence pyramid icons are associated with directory
6480N/A servers.</
para></
footnote> The distinguished name consists of components
6480N/A <
literal>uid=bjensen,ou=People,dc=example,dc=com</
literal>. The names are
6480N/A little-endian. The components reflect the hierarchy of directory entries.</
para>
6480N/A <
mediaobject xml:
id="figure-data-organization">
6480N/A <
alt>Directory data hierarchy as seen in OpenDJ Control Panel.</
alt>
6480N/A <
para>You can see the hierarchy of directory data in the left pane of
6480N/A the Manage Entries browser.</
para>
6480N/A <
para>Barbara Jensen's entry is located under an entry with DN
6480N/A <
literal>ou=People,dc=example,dc=com</
literal>, an organization unit and
6480N/A <
literal>ou=People</
literal> entry is located under the entry with DN
6480N/A DC stands for domain component. The directory has other base entries, such
6480N/A as <
literal>cn=config</
literal>, under which the configuration is accessible
6480N/A through LDAP. A directory can serve multiple organizations, too. You might
6480N/A find <
literal>dc=example,dc=com</
literal>,
6480N/A <
literal>dc=mycompany,dc=com</
literal>, and
6480N/A <
literal>o=myOrganization</
literal> in the same LDAP directory.
6480N/A Therefore when you look up entries, you specify the base DN to look under
6480N/A in the same way you need to know whether to look in the New York, Paris,
6480N/A or Tokyo phone book to find a telephone number.<
footnote>
6480N/A <
para>The root entry for the directory, technically the entry with DN
6480N/A <
literal>""</
literal> (the empty string), is called the root DSE, and
6480N/A contains information about what the server supports, including the other
6480N/A base DNs it serves.</
para></
footnote></
para>
7288N/A A directory server stores two kinds of attributes in a directory entry:
7288N/A <
firstterm>user attributes</
firstterm>
7288N/A and <
firstterm>operational attributes</
firstterm>.
7288N/A User attributes hold the information for users of the directory.
7288N/A All of the attributes shown in the entry at the outset of this section
7288N/A Operational attributes hold information used by the directory itself.
7288N/A Examples of operational attributes include
7288N/A <
literal>entryUUID</
literal>, <
literal>modifyTimestamp</
literal>,
7288N/A and <
literal>subschemaSubentry</
literal>.
7288N/A When an LDAP search operation finds an entry in the directory,
7288N/A the directory server returns all the visible user attributes
7288N/A unless the search request restricts the list of attributes
7288N/A by specifying those attributes explicitly.
7288N/A The directory server does not however return any operational attributes
7288N/A unless the search request specifically asks for them.
7288N/A Generally speaking, applications should change only user attributes,
7288N/A and leave updates of operational attributes to the server,
7288N/A relying on public directory server interfaces to change server behavior.
7288N/A An exception is access control instruction (<
literal>aci</
literal>) attributes,
7288N/A which are operational attributes used to control access to directory data.
6480N/A <
section xml:
id="ldap-client-server-communication">
6480N/A <
title>About LDAP Client & Server Communication</
title>
6480N/A <
para>In some client server communication, like web browsing, a connection is
6480N/A set up and then torn down for each client request to the server. LDAP has a
6480N/A different model. In LDAP the client application connects to the server and
6480N/A authenticates, then requests any number of operations, perhaps processing
6480N/A results in between requests, and finally disconnects when done.</
para>
6480N/A <
itemizedlist xml:
id="standard-ldap-operations">
6480N/A <
para>The standard operations are as follows.</
para>
6480N/A <
para>Bind (authenticate). The first operation in an LDAP session usually
6480N/A involves the client binding to the LDAP server, with the server
6480N/A authenticating the client.<
footnote><
para>If the client does not bind
6480N/A explicitly, the server treats the client as an anonymous client. The client
6480N/A can also bind again on the same connection.</
para></
footnote> Authentication
6480N/A identifies the client's identity in LDAP terms, the identity which is later
6480N/A used by the server to authorize (or not) access to directory data that the
6480N/A client wants to lookup or change.</
para>
6480N/A <
para>Search (lookup). After binding, the client can request that the server
6480N/A return entries based on an LDAP filter, which is an expression that the
6480N/A server uses to find entries that match the request, and a base DN under
6480N/A which to search. For example, to lookup all entries for people with email
6480N/A you would specify a base DN such as
6480N/A <
literal>ou=People,dc=example,dc=com</
literal> and the filter
6480N/A <
literal>(mail=bjensen@example.com)</
literal>.</
para>
6480N/A <
para>Compare. After binding, the client can request that the server
6480N/A compare an attribute value the client specifies with the value stored
6480N/A on an entry in the directory.</
para>
6480N/A <
para>This operation is not used as commonly as others.</
para>
6480N/A <
para>Modify. After binding, the client can request that the server
6480N/A change one or more attribute values on an entry. Often administrators
6480N/A do not allow clients to change directory data, so allow appropriate access
6480N/A for client application if they have the right to update data.</
para>
6480N/A <
para>Add. After binding, the client can request to add one or more
6480N/A new LDAP entries to the server. </
para>
6480N/A <
para>Delete. After binding, the client can request that the server
6480N/A delete one or more entries. To delete and entry with other entries
6480N/A underneath, first delete the children, then the parent.</
para>
6480N/A <
para>Modify DN. After binding, the client can request that the server
6480N/A change the distinguished name of the entry. In other words, this renames
6480N/A the entry or moves it to another location. For example, if Barbara
6480N/A changes her unique identifier from <
literal>bjensen</
literal> to something
6480N/A else, her DN would have to change. For another example, if you decide
6480N/A to consolidate <
literal>ou=Customers</
literal> and
6480N/A <
literal>ou=Employees</
literal> under <
literal>ou=People</
literal>
7288N/A instead, all the entries underneath must change distinguished names.
6480N/A <
footnote><
para>Renaming entire branches of entries can be a major
6480N/A operation for the directory, so avoid moving entire branches if you
6480N/A can.</
para></
footnote></
para>
6480N/A <
para>Unbind. When done making requests, the client can request an
6480N/A unbind operation to end the LDAP session.</
para>
6480N/A <
para>Abandon. When a request seems to be taking too long to complete,
6480N/A or when a search request returns many more matches than desired, the client
6480N/A can send an abandon request to the server to drop the operation in
6480N/A <
para>For practical examples showing how to perform the key operations using
6480N/A the command line tools delivered with OpenDJ directory server, read
6480N/A <
link xlink:
show="new" xlink:
href="admin-guide#chap-ldap-operations" 6480N/A Operations</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="standard-ldap-controls-extensions">
6480N/A <
title>About LDAP Controls & Extensions</
title>
6480N/A <
para>LDAP has standardized two mechanisms for extending what directory
6480N/A servers can do beyond the basic operations listed above. One mechanism
6480N/A involves using LDAP controls. The other mechanism involves using LDAP extended
6480N/A <
primary>LDAP controls</
primary>
6480N/A <
secondary>About</
secondary>
6480N/A <
para>LDAP controls are information added to an LDAP message to further
6480N/A specify how an LDAP operation should be processed. For example, the
6480N/A Server Side Sort Request Control modifies a search to request that the
6480N/A directory server return entries to the client in sorted order. The Subtree
6480N/A Delete Request Control modifies a delete to request that the server
6480N/A also remove child entries of the entry targeted for deletion.</
para>
6480N/A <
para>One special search operation that OpenDJ supports is Persistent
6480N/A Search. The client application sets up a Persistent Search to continue
6480N/A receiving new results whenever changes are made to data that is in the
6480N/A scope of the search, thus using the search as a form of change notification.
6480N/A Persistent Searches are intended to remain connected permanently, though
6480N/A they can be idle for long periods of time.</
para>
6480N/A <
para>The directory server can also send response controls in some cases to
6480N/A indicate that the response contains special information. Examples include
6480N/A responses for entry change notification, password policy, and paged results.</
para>
6480N/A <
para>For the list of supported LDAP controls, see
7321N/A <
link xlink:
show="new" xlink:
href="reference#appendix-controls" 6480N/A Controls</
citetitle></
link>.</
para>
6480N/A <
primary>LDAP extended operations</
primary>
6480N/A <
secondary>About</
secondary>
6480N/A <
para>LDAP extended operations are additional LDAP operations not included
6480N/A in the original standard list. For example, the Cancel Extended Operation
6480N/A works like an abandon operation, but finishes with a response from the
6480N/A server after the cancel is complete. The StartTLS Extended Operation allows
6480N/A a client to connect to a server on an unsecure port, but then start
6480N/A Transport Layer Security negotiations to protect communications.</
para>
6480N/A <
para>For the list of supported LDAP extended operations, see
7321N/A <
link xlink:
show="new" xlink:
href="reference#appendix-extended-ops" 6480N/A Operations</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="about-indexes">
6480N/A <
title>About Indexes</
title>
6480N/A <
para>As mentioned early in this chapter, directories have indexes for
6480N/A multiple attributes. In fact by default OpenDJ does not let normal users
6480N/A perform searches that are not indexed, because such searches mean OpenDJ
6480N/A has to scan the entire directory looking for matches.</
para>
6480N/A <
para>As directory administrator, part of your responsibility is making sure
6480N/A directory data is properly indexed. OpenDJ provides tools for building
6480N/A and rebuilding indexes, for verifying indexes, and also for evaluating
6480N/A how well they are working.</
para>
6480N/A <
para>For help better understanding and managing indexes, read the chapter
6480N/A <
link xlink:
show="new" xlink:
href="admin-guide#chap-indexing" 6480N/A Attribute Values</
citetitle></
link>.</
para>
6481N/A <
section xml:
id="schema-overview">
6480N/A <
title>About LDAP Schema</
title>
6480N/A <
para>Some databases are designed to hold huge amounts of data for a
6480N/A particular application. Although such databases might support multiple
6480N/A applications, how their data is organized depends a lot on the particular
6480N/A applications served.</
para>
6480N/A <
para>In contrast, directories are designed for shared, centralized services.
6480N/A Although the first guides to deploying directory services suggested taking
6480N/A inventory of all the applications that would access the directory, many
6480N/A directory administrators today do not even know how many applications use
6480N/A their services. The shared, centralized nature of directory services fosters
6480N/A interoperability in practice, and has helped directory services be successful
6480N/A <
para>Part of what makes this possible is the shared model of directory user
6480N/A information, and in particular the LDAP schema. LDAP schema defines what the
6480N/A directory can contain. This means that directory entries are not arbitrary
6480N/A data, but instead tightly codified objects whose attributes are completely
6480N/A predictable from publicly readable definitions. Many schema definitions are
6480N/A in fact standard, and so are the same not just across a directory service but
6480N/A across different directory services.</
para>
6480N/A <
para>At the same time, unlike some databases, LDAP schema and the data it
6480N/A defines can be extended on the fly while the service is running. LDAP schema
6480N/A is also accessible over LDAP. One attribute of every entry is its set of
6480N/A <
literal>objectClass</
literal> values. This gives you as administrator great
6480N/A flexibility in adapting your directory service to store new data without
6480N/A losing or changing the structure of existing data, and also without ever
6480N/A stopping your directory service.</
para>
6480N/A <
para>For a closer look, see <
link xlink:
show="new" 6480N/A xlink:
href="admin-guide#chap-schema" 6480N/A Schema</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="about-access-control">
6480N/A <
title>About Access Control</
title>
6480N/A <
primary>Access control</
primary>
6480N/A <
para>In addition to directory schema, another feature of directory services
6480N/A that enables sharing is fine-grained access control.</
para>
6480N/A <
para>As directory administrator, you can control who has access to what
6480N/A data when, how, where and under what conditions by using access control
6480N/A instructions (ACI). You can allow some directory operations and not others.
6480N/A You can scope access control from the whole directory service down to
6480N/A individual attributes on directory entries. You can specify when, from what
6480N/A host or IP address, and what strength of encryption is needed in order to
6480N/A perform a particular operation.</
para>
6480N/A <
para>As ACIs are stored on entries in the directory, you can furthermore
6480N/A update access controls while the service is running, and even delegate that
6480N/A control to client applications. OpenDJ combines the strengths of ACIs with
6480N/A separate administrative privileges to help you secure access to directory
6480N/A <
para>For more, read <
link xlink:
show="new" 6480N/A xlink:
href="admin-guide#chap-privileges-acis" 6480N/A Privileges & Access Control</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="about-replication">
6480N/A <
title>About Replication</
title>
6480N/A <
para>Replication in OpenDJ consists of copying each update to the directory
6480N/A service to multiple directory servers. This brings both redundancy in the
6480N/A case of network partitions or of crashes, and also scalability for read
6480N/A operations. Most directory deployments involve multiple servers replicating
6480N/A <
para>When you have replicated servers, all of which are writable, you can
6480N/A have replication conflicts. What if, for example, there is a network outage
6480N/A between two replicas, and meanwhile two different values are written to the
6480N/A same attribute on the same entry on the two replicas? In nearly all cases,
6480N/A OpenDJ replication can resolve these situations automatically without
6480N/A involving you, the directory administrator. This makes your directory service
6480N/A resilient and safe even in the unpredictable real world.</
para>
6480N/A <
para>One perhaps counterintuitive aspect of replication is that although you
6480N/A do add directory <
emphasis>read</
emphasis> capacity by adding replicas to
6480N/A your deployment, you do not add directory <
emphasis>write</
emphasis> capacity
6480N/A by adding replicas. As each write operation must be replayed everywhere, the
6480N/A result is that if you have N servers, you have N write operations to
6480N/A <
para>Another aspect of replication to keep in mind is that it is "loosely
6480N/A consistent." Loosely consistent means that directory data will eventually
6480N/A converge to be the same everywhere, but it will not necessarily be the same
6480N/A everywhere right away. Client applications sometimes get this wrong when they
6480N/A write to a pool of load-balanced directory servers, immediately read back
6480N/A what they wrote, and are surprised that it is not the same. If your users
6480N/A are complaining about this, either make sure their application always gets
6480N/A sent to the same server, or else ask that they adapt their application to
6480N/A work in a more realistic manner.</
para>
6480N/A <
para>To get started with replication, see <
link xlink:
show="new" 6480N/A xlink:
href="admin-guide#chap-replication" 6480N/A Replication</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="directory-services-markup-language">
6480N/A <
title>About DSMLv2</
title>
6480N/A <
para>Directory Services Markup Language (DSML) was developed starting in 1999
6480N/A and v2.0 became a standard in 2001. DSMLv2 describes directory data and basic
6480N/A directory operations in XML format, allowing them to be carried in SOAP
6480N/A messages. DSMLv2 further allows clients to batch multiple operations together
6480N/A in a single request, to be processed either in sequential order or in
6480N/A <
para>OpenDJ provides support for DSMLv2 as a DSML gateway, which is a Servlet
6480N/A that connects to any standard LDAPv3 directory. DSMLv2 opens basic directory
6480N/A services to SOAP based web services and service oriented architectures.</
para>
6480N/A <
para>To set up DSMLv2 access, see <
link xlink:
show="new" 6480N/A xlink:
href="admin-guide#setup-dsml" 6480N/A Access</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="rest-and-ldap">
6480N/A <
title>About RESTful Access to Directory Services</
title>
6480N/A <
para>OpenDJ can expose directory data as JSON resources over HTTP to REST
6480N/A clients, providing easy access to directory data for developers who are not
6480N/A familiar with LDAP. RESTful access depends on configuration that describes
6480N/A how the JSON representation maps to LDAP entries.</
para>
6480N/A <
para>Although client applications have no need to understand LDAP, OpenDJ's
6480N/A underlying implementation still uses the LDAP model for its operations. The
6480N/A mapping adds some overhead. Furthermore, depending on the configuration,
6480N/A individual JSON resources can require multiple LDAP operations. For example,
6480N/A an LDAP user entry represents <
literal>manager</
literal> as a DN (of the
6480N/A manager's entry). The same manager might be represented in JSON as an object
6480N/A holding the manager's user ID and full name, in which case OpenDJ must look
6480N/A up the manager's entry to resolve the mapping for the manager portion of the
6480N/A JSON resource, in addition to looking up the user's entry. As another example,
6480N/A suppose a large group is represented in LDAP as a set of 100,000 DNs. If the
6480N/A JSON resource is configured so that a member is represented by its name, then
6480N/A listing that resource would involve 100,000 LDAP searches to translate DNs to
6480N/A <
para>A primary distinction between LDAP entries and JSON resources is that
6480N/A LDAP entries hold sets of attributes and their values, whereas JSON resources
6480N/A are documents containing arbitrarily nested objects. As LDAP data is governed
6480N/A by schema, almost no LDAP objects are arbitrary collections of data.
6480N/A <
footnote><
para>LDAP has the object class <
literal>extensibleObject</
literal>,
6480N/A but its use should be the exception rather than the rule.</
para></
footnote>
6480N/A Furthermore, JSON resources can hold arrays, ordered collections that can
6480N/A contain duplicates, whereas LDAP attributes are sets, unordered collections
6480N/A without duplicates. For most directory and identity data, these distinctions
6480N/A do not matter. You are likely to run into them however if you try to turn
6480N/A your directory into a document store for arbitrary JSON resources.</
para>
6480N/A <
para>Despite some extra cost in terms of system resources, exposing directory
6480N/A data over HTTP can unlock your directory services for a new generation of
6480N/A applications. The configuration provides flexible mapping, so that you can
6480N/A configure views that correspond to how client applications need to see
6480N/A directory data. OpenDJ also gives you a deployment choice for HTTP access.
6480N/A You can deploy the REST LDAP gateway, which is a Servlet that connects to
6480N/A any standard LDAPv3 directory, or you can activate the HTTP Connection Handler
6480N/A on OpenDJ itself to allow direct and more efficient HTTP and HTTPS
6480N/A <
para>For examples showing how to use RESTful access, see the chapter on
6480N/A <
link xlink:
show="new" xlink:
href="admin-guide#chap-rest-operations" 6480N/A RESTful Operations</
citetitle></
link>.</
para>
6480N/A <
section xml:
id="about-building-directory-services">
6480N/A <
title>About Building Directory Services</
title>
6480N/A <
para>This chapter is meant to serve as an introduction, and so does not
6480N/A even cover everything in this guide, let alone everything you might want
6480N/A to know about directory services.</
para>
6480N/A <
para>When you have understood enough of the concepts to build the directory
6480N/A services you want to deploy, you must still build a prototype and test it
6480N/A before you roll out shared, centralized services for your organization.
6480N/A Read the chapter on <
link xlink:
show="new" 6480N/A xlink:
href="admin-guide#chap-tuning" 6480N/A For Performance</
citetitle></
link> for a look at how to meet the service
6480N/A levels your clients expect.</
para>
