Future Directions: Where Is LDAP Headed Next?

   

Future Directions: Where Is LDAP Headed Next ?

Over the past few years , LDAP has steadily gained mindshare and acceptance in the marketplace . In the future, we believe that LDAP will become ubiquitous and evolve as described in the discussion that follows .

Increased Integration into Operating Systems and Infrastructure Middleware

In the late 1990s, Novell and Microsoft embraced LDAP as a core technology for their operating systems. They were the first operating system (OS) vendors to integrate LDAP deeply into core OS offerings. Since then, other OS vendors, most notably Sun Microsystems, have integrated LDAP into their operating systems, and they use directories to distribute user , group , and other information. This trend will continue, with OS vendors replacing their legacy naming servers (such as NIS and NIS+) with LDAP.

Middleware vendors have also integrated LDAP into their offerings. Application servers and other middleware tools from companies including Netscape and Netegrity, as well as infrastructure management applications from companies such as Access360, all use LDAP as their store of information about users, groups, and access to protected resources.

Emerging Standards Work

At the time of this writing, three major LDAP- related work topics are being addressed in the IETF: an update to the core LDAPv3 protocol, establishment of a common access control model for LDAP, and development of a vendor-neutral client update protocol.

An Update to the LDAP Standard

The LDAPBIS Working Group has recently been formed to update the LDAPv3 standards and move them from IETF Proposed Standard status (their current status as of the time of this writing) to Draft Standard status, the next level in the IETF standards process. For more information, see the LDAPBIS Working Group page at http://www.ietf.org/html. charters /ldapbis-charter.html.

Access Control Model for LDAP

Work is under way to establish a vendor-neutral access control model for LDAP. Establishment of a common access control model will facilitate consistent secure access, replication, and management across heterogeneous LDAP implementations .

At this time, a requirements document, Access Control Requirements for LDAP , has been published as RFC 2820. This document outlines the requirements that subsequent access control models must meet. A proposed access control model that is intended to meet these requirements is being developed.

LDAP Client Update Protocol (LCUP)

The LDAP Client Update Protocol (LCUP) is a method for synchronizing cached copies of directory information, such as copies maintained by offline directory clients and high-performance middleware components and application servers. See LDAP Client Update Protocol (http://www.ietf.org/internet-drafts/draft-ietf-ldup-lcup-03.txt).

Other LDAP-Related Standards Work

Smaller projects are under way in the IETF to define new controls, extended operations, and SASL mechanisms that extend LDAPv3. Some current projects under way at the time of this writing include

  • The StartTLS extended operation, which allows a client to begin using TLS on an already established LDAP connection. For more information, see RFC 2830, Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security (http://www.ietf.org/rfc/rfc2830.txt).

  • Development of a method for accessing the directory using UDP, a connectionless protocol. See Lightweight Directory Access Protocol over UDP/IP (http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapudp-00.txt).

  • Ways to use the Domain Name System (DNS) to locate LDAP servers. See A Taxonomy of Methods for LDAP Clients Finding Servers (http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-taxonomy-05.txt).

  • Standardization of the C and Java LDAP APIs. See The C LDAP Application Program Interface (http://mozilla.org/directory/ietf-docs/draft-ietf-ldapext-ldap-c-api-05.txt) and The Java LDAP Application Program Interface (http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-18.txt).

LDAP and XML

eXtensible Markup Language (XML) is revolutionizing the way information is exchanged on the Internet. A variety of common tools and techniques have been developed to make it easier to create an XML-based application and to move XML data into and out of a huge variety of data sources, from relational database management systems (RDBMSs) to LDAP directories. XML is a metalanguage that allows document formats to be created that not only have structure but also convey semantic meaning about their contents.

LDAP directories are also all about structure and meaning: Directory entries usually describe real-world objects, their qualities (attributes), and their relationships to other objects in the directory. It's therefore not surprising that XML provides a convenient way to describe directory information. In fact, if XML had been available when the first LDAP implementations were being written, it would have been used as the data interchange format instead of LDIF. In the more distant future, an XML-based directory markup format will probably replace LDIF.

DSML

The current XML industry standard for how to describe directory data is DSML, or Directory Services Markup Language. It was developed by a consortium of companies including Bowstreet, IBM, Netscape, Microsoft, Novell, and Oracle. The specification is managed by the Organization for the Advancement of Structured Information Standards (OASIS).

The currently published version of the DSML specification is 2.0. An XML document conforming to DSML 2.0 contains directory entries and, optionally , schema information. Additionally, DSML 2.0 documents can describe directory queries as well as updates to be applied to a directory.

A directory entry in DSML format might look like Listing 3.5. In LDIF format, the same entry would look like Listing 3.6.

Listing 3.5 A Directory Entry Represented in DSML 2.0 Format
 <dsml:entry dn="uid=bjensen,ou=people,dc=example,dc=com">   <dsml:objectclass>     <dsml:oc-value>top</dsml:oc-value>     <dsml:oc-value>person</dsml:oc-value>     <dsml:oc-value>organizationalPerson</dsml:oc-value>     <dsml:oc-value>inetOrgPerson</dsml:oc-value>   </dsml:objectclass>   <dsml:attr name="cn">     <dsml:value>Barbara Jensen</dsml:value>     <dsml:value>Babs Jensen</dsml:value>   </dsml:attr>   <dsml:attr name="sn"><dsml:value>Jensen</dsml:value></dsml:attr>   <dsml:attr name="uid"><dsml:value>bjensen</dsml:value></dsml:attr>   <dsml:attr name="mail">     <dsml:value>bjensen@example.com</dsml:value>   </dsml:attr>   <dsml:attr name="givenname">     <dsml:value>Barbara</dsml:value>   </dsml:attr> </dsml:entry> 
Listing 3.6 The Directory Entry of Listing 3.5 Represented in LDIF Format
 dn: uid=bjensen,ou=people,dc=example,dc=com objectclass: top obejctclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen sn: Jensen uid: bjensen mail: bjensen@example.com givenname: Barbara 

The DSML format, although more verbose, is more easily read by a machine and doesn't suffer from some of the parsing problems inherent in the LDIF format. In addition, because XML parsers are readily available, it's easy to adapt one to read DSML. Moreover, although not shown in the example, DSML can carry schema information. This capability allows the reader of a DSML document to better understand the meaning of the attributes contained in the DSML file, without schema information having to be exchanged via another method.

Another useful quality of DSML is its compatibility with protocols such as XML-RPC (XML-Remote Procedure Call) and SOAP (Simple Object Access Protocol) that transmit XML, typically using the Hypertext Transfer Protocol (HTTP) and the HTTP-over-SSL (HTTPS) protocols. This feature has several advantages for developers. First, tools for marshaling XML into XML-RPC and SOAP messages are readily available, making development much easier. Second, firewalls are often configured to allow HTTP and HTTPS protocols to pass. These two facts make it possible for DSML, carried in the HTTP or HTTPS protocol, to become the method of choice for carrying directory data on the public Internet.

Does this mean the death of the LDAP protocol? Probably not. Whereas DSML and other XML directory standards will probably appeal to people writing XML applications, LDAP will appeal to people who are directory savvy and directory centric. Although HTTP and HTTPS transports are ubiquitous and well understood , the LDAP protocol is better suited to writing client applications that need to achieve high throughput to the directory. For example, HTTP doesn't support multiple concurrent requests , whereas LDAP does. LDAP will likely be the protocol of choice for communication between the infrastructure components behind e-commerce applications, whereas DSML and HTTP/HTTPS will be the means for communicating directory data between enterprises .

   


Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 2002
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net