The LDAP class library is designed to provide powerful, yet simple, access to a LDAP directory services. It defines both asynchronous and synchronous interfaces (explained later) to LDAP, with support for partial results on searching, to suit a wide variety of applications. Roughly speaking, an LDAP library session corresponds to a single connection to an LDAP directory server. The LDAP library hides most of the connection-related details.
The general sequence for retrieving the data is as follows:
STEP I : Initialize the library and obtain an LDAP session handle
STEP II : Initiate an LDAP operation, and wait for any result(s)
STEP III: Process the result(s)
STEP IV: Dispose of the LDAP session handle obtained in STEP I
SYNCHRONOUS VS ASYNCHRONOUS CONNECTIONS
The synchronous functions combine initiating a request and waiting for the server’s response. A connection is established, a request is sent, the results are returned, and the application resumes. Though it can deliver one search result at a time, other operations block until completion when accessing an LDAP server. Synchronous methods wait for response messages from a server and then process them.
Asynchronous methods require you to check for the messages and perform the processing in your code. This allows you to make additional LDAP requests while waiting for results to return. The LDAP protocol is completely asynchronous in that multiple operations can be underway at the same time and the directory server can perform the operations and return results in any order. Each message that is passed in the protocol is tagged with a number called the “message ID”, that is unique for a given session. This feature of LDAP supports complex applications that want to initiate several operations at once, without opening multiple connections to the server.
APIs FOR RETRIEVING THE DATA
I JNDI API:
The Java Naming and Directory Interface (JNDI) allows Java applications to use a single set of methods to access multiple naming and directory services such as LDAP. JNDI is a Java API that provides a common way for programmers to access a variety of naming and directory services.
JNDI operates through a layer of software called a Service Provider. The Service Provider implements the JNDI operations in terms of a particular underlying protocol. JNDI’s Service Provider Interface (SPI) allows you to select Service Providers (Example: Netscape’s LDAP service provider) at runtime. In many cases you can use the same JNDI methods regardless of whether the Service Provider is talking to an LDAP server or using another protocol.
ARCHITECTURE: The JNDI architecture consists of the JNDI API and the JNDI SPI. The JNDI API allows Java applications to access a variety of naming and directory services. The JNDI SPI is designed to be used by arbitrary service providers including directory service providers. This enables a variety of directory and naming services to be plugged in transparently to the Java application (which uses only the JNDI API). Figure shows the JNDI architecture and includes a few service providers of directory and naming contexts as examples.
INTERFACE:
The JNDI API is contained in four packages:
Ø javax.naming contains classes and interfaces for accessing naming services
Ø javax.naming.directory extends the core javax.naming package to provide access to directories
Ø javax.naming.event contains classes and interfaces for supporting event notification in naming and directory services
Ø javax.naming.ldap contains classes and interfaces for supporting LDAP v3 extensions and controls
The JNDI SPI (service provider interface) is contained in one package:
Ø javax.naming.spi contains classes and interfaces that allow various naming and directory service providers to be dynamically plugged in beneath the JNDI API
The idea is that each package contains the interfaces and classes required for a particular category of applications. For example, an application that just wants to perform name-lookups only needs to use the javax.naming package. An application that wants to examine/modify attributes associated with an object uses the javax.naming and javax.naming.directory packages. An application that needs to use LDAP-specific controls or extended operations uses the javax.naming.ldap package.
II LDAP API
The LDAP programmer’s API includes more than 50 distinct functions. One way to categorize the LDAP API is by separating the functions that are used to initiate LDAP protocol operations and receives results over the network from those that do other things.
STEP I: Initialize the Library and obtain A Session Handle:
The LDAP session handle is of type LDAP * and is the first parameter passed to nearly all of the LDAP API functions. All applications that access an LDAP directory server will need to call one of two initialization functions:
Ø ldap_init( ): Initializes the LDAP library and returns a session handle for use in subsequent calls.
Ø ldap_open ( ): Initializes the LDAP library, connects to a directory server and returns a session handle for use in subsequent calls.
These functions return an LDAP session handle, which must be passes as the first argument to most of the other LDAP API calls. The above functions do not actually open a network connection to the server – this will be done by the LDAP library when the first call is made that actually needs to communicate with the server. They only allocate a data structure called the LDAP session handle and returns a pointer to it to the caller. Even though ldap_open is sometimes used, the preferred method of obtaining an LDAP session handle is to use the ldap_init( ) call.
STEP II: Initiate an LDAP Operation and Wait for Results:
This is where the network action occurs. One of the core LDAP functions is called to send an LDAP request to the directory server.
Ø ldap_search ( ) : Searches the directory entries
Ø ldap_compare ( ): sees if an entry contains a given attribute value
Ø ldap_bind ( ): Authenticates to a directory server
Ø ldap_modify ( ): Makes changes to an existing directory entry
Ø ldap_add ( ): Adds a new directory entry
Ø ldap_delete ( ): Deletes an existing directory entry
Ø ldap_modrdn ( ): renames an existing directory entry
Ø ldap_result ( ): retrieves the result(s) of one of the previous operations
The result includes a result code (typically, ldap_success, if all went well) and may include other error-related information. For an LDAP search operation, one or more entries may also be returned by the server before the LDAP result. This process of initiating the LDAP operation and receiving entries and the result may be done synchronously (in which case a single LDAP API function is called) or it may be done asynchronously (in which case several simple functions are called).
Most directory servers will allow searching of non-confidential information when you are bound as the anonymous user, but they will probably disallow access to sensitive information and will almost certainly not allow changes to be made to directory information unless you identify yourself.
STEP III: Process the Result(s):
This is where the application makes use of the data that was returned. For all operations except search, there is probably very little work to do. Depending on the purpose of the ldap_search call, further functions need to be called.
Ø ldap_get_values ( ): to obtain attribute value form the entry.
Ø ldap_first_entry ( ) : to obtain the first entry
Ø ldap_next_entry ( ): to step through the entries
Ø ldap_get_dn ( ): to retrieve the name of each entry
Once the results are obtained back from a search, the API allows to parse the results and extract particular pieces of information from each entry returned, including the entry’s name and associated attributes and values.
STEP IV: Dispose of the LDAP Session Handle:
This is done when you are completely finished with an LDAP session.
Ø Ldap_unbind ( ): Terminates an LDAP session
It is an error to reference an LDAP session handle after it has been disposed off.
CONCLUSION:
Directories have a bright future on the Internet, and LDAP promises to make life easier for both users and application developers. From a central place to store and find information about yourself and other users, to a general configuration, preference, and management store for enterprise-wide administration, LDAP clearly has the potential to deliver on the promise of a distributed computing environment.
Of course, integration with applications is the key to unlocking this potential. It is relatively easy to write applications to search and retrieve the data from LDAP. This can be done either using the JNDI API or the LDAP API. While the JNDI API accesses multiple naming and directory services other than LDAP, the functions in the LDAP API is specifically meant for accessing the LDAP Directory Sever.
No comments:
Post a Comment