LDAP Client Options - LDAP Directories Explained

The LDAP API is an important component of the LDAP framework

LDAP client options allow the LDAP client to specify standard settings for the duration of an LDAP client session, as opposed to a single operation. LDAP client options apply to a server session; so if a client has a session open to two different servers, the options set on one session do not apply to the other server session. LDAP client options are different from LDAP attribute options (for more detail on these, see Chapter 4). The LDAP C API designates several standard client options, and any LDAP implementation can define new ones. The following list comprises some of the options listed in the API RFC:

 LDAP_OPT_DEREF

This option allows the client to control how aliases are handled. The valid values are - LDAP_DEREF_NEVER: Never dereference aliases.

- LDAP_DEREF_SEARCHING: Don't dereference an alias at the base DN, but dereference otherwise.

- LDAP_DEREF_FINDING: Dereference an alias at the base DN, but don't dereference otherwise.

- LDAP_DEREF_ALWAYS: Always dereference.

 LDAP_OPT_SIZELIMIT

This option controls the maximum number of entries that can be returned.

 LDAP_OPT_TIMELIMIT

This option controls the maximum amount of time the server spends completing an operation.

 LDAP_OPT_REFERRALS

This option controls whether the client chases referrals. The valid values are - LDAP_OPT_ON: Chase all referrals.

- LDAP_OPT_SUBORDINATE_REFERRALS: Chase only subordinate referrals.

- LDAP_OPT_EXTERNAL_REFERRALS: Chase only external referrals.

Significant options not defined in the API RFC that Mycompany may want its vendor to support include:

 LDAP_OPT_SSL

This option directs the client to use SSL on client connections.

 LDAP_OPT_REFERRAL_HOP_LIMIT

This option sets the maximum number of referrals a client will chase on a single operation.

[ Team LiB ]

APIs

LDAP client options set parameters for an entire session

The C language LDAP application program interface (API) specified in RFC 1823 is not part of the LDAP standard. However, it is critically important because it helps to define a base framework for programmatically interacting with an LDAP server. Even though this RFC is not part of the standard, almost all vendors implement it. This RFC is an unofficial part of the standard by sheer use and implementation. This RFC is based on the LDAP v2 standard. There is work in progress to produce a replacement RFC that covers LDAP v3.

API calls mostly map to the standard server operations

The function calls specified in RFC 1823 mostly map to the basic LDAP operations. For example, consider the server operation used to add entries. There is a standard API function called

ldap_add()

that a client program would use to ask the server to perform the add operation.

Each function has a real-time version and a version that combines results into a single response For each function, there are usually two versions. A synchronous version blocks until all results are available. The program calling a synchronous version doesn't get control until the server finishes replying to the request. The asynchronous version immediately returns a message ID. The program can then use other functions (supplying the message ID) to determine when the server has

returned results for the operation. The synchronous versions are easier to use, but the

asynchronous versions give your program greater efficiency and freedom at the cost of managing multiple requests/replies. The synchronous versions have a "_s" appended to the end of the function name, while the asynchronous versions do not. For example the synchronous version of the add operation is

ldap_add_s()

, whereas the asynchronous version is

ldap_add()

Additional versions of functions offer other functionality

Several of the functions have more than just the synchronous and asynchronous versions. Some of the functions support slightly different functionality. Each set of versions of a function is loosely called a family, or friends of the primary function.

The LDAPMessage structure holds the results of the client's request, and it can be manipulated by functions

Results or errors from the primary operation function calls are returned via a special data structure called the LDAPMessage. The results in this structure can then be accessed by function calls that do not map to the primary LDAP operations. These other functions allow you to step through results or errors as you see fit. For example, one such function,

ldap_first_entry()

, calls the first entry returned in the LDAPMessage. This entry can then be stepped through with functions like

ldap_first_attribute()

. The functions

ldap_next_entry()

and

ldap_next_attribute()

allow you to step to the next entry and attribute, respectively.

LDAP API functions are flexible and easy to use

For a list of the functions defined in the LDAP API, see Appendix A. All the functions are included to highlight the flexibility available, should your organization want to develop applications that use their LDAP directory. In addition, the complete listing serves as a quick reference for developers getting started with the LDAP API. Each function is accompanied by a short description. More details on these functions can be found in the RFC, and programmers will want to consult vendor-specific

API implementations for differences or significant additional functions.

API libraries in almost every language and platform are available

There are many different implementations of LDAP APIs in a multitude of languages. Netscape's LDAP SDK provides APIs in C, perl, and Java. Sun provides JNDI, a Java API. The PerLDAP SDK uses the perl language. Microsoft provides the ADSI SDK, which can be used with any COM-compliant language, such as C, C+, Visual Basic, Java, and VBScript. Many other APIs exist, including ones for PHP, ODBC, server-side JavaScript, ColdFusion, and others. Books on using the APIs and online resources should make it easy for a programmer to locate and learn whatever is needed.

[ Team LiB ]

Summary

LDAP operational functionality benefits from a unique blend of standardization and entrepreneurship The client-server operational functionality of LDAP directories is largely standardized across every vendor's product. This provides a baseline of interoperability that is critical to LDAP's success. You will find this baseline invaluable when you want to centralize directory information. However, the operational functionality is not fixed or limited by the standards. Both the extended operation and LDAP controls provide a means for operational extension. This allows vendors to create unique and powerful enhancements that advance the usefulness of LDAP directories. Not all the operational functionality of LDAP directories is tied to the client-server interaction. In fact, the standard is largely silent about server-to-server interactions. For more detail on this topic, see Chapter 5.

[ Team LiB ]

In document LDAP Directories Explained (Page 80-85)