Chapter 8: LDAP and Web Services

---

Introduction

Chapter 6 suggested several ways of integrating directory services into applications. Most programming languages have libraries that allow direct communication with directory servers. This chapter focuses on the collaboration of two different protocols: the LDAP protocol and the HTTP protocol.

The user-friendly HTTP is the language spoken on the Internet, used almost exclusively for communicating between Web servers and Web browsers. In contrast, LDAP is not very user friendly. However, LDAP is the ideal solution for directory applications, such as the frequently cited example of the "white pages."

In Chapter 6, we saw application programming interfaces (API) as one way of shielding the user from the complexity of LDAP. Sometimes the only reason for an application is to help the user access the data hosted by a directory server. In such cases, the application serves only as an interface to the directory, allowing the users to access the data stored there. Sometimes the application itself needs access to directory services to work properly. An example could be an application making lookups for user groups when LDAP substitutes for NIS+, the Network Information System developed by Sun Microsystems.

Web services provide another easy way to access directories. This chapter focuses on Web services and LDAP. Strictly defined, Web services are nothing more than an API. A Web server is a server application listening on a certain port (normally port 80) for connections coming from a client application. The client application typically is the familiar Web browser.

Although Web services are indeed normal applications, there are a number of characteristics of Web services that require particular attention for those who develop programs in this environment. In some senses, LDAP is similar to HTTP. Both are protocols located over the TCP/IP stack; both have similar security aspects; and both are client-server applications. However, the similarity ends there. LDAP is a connection-oriented protocol, and HTTP is not. But let us return to the argument. The development of Web services requires a particular method of programming. In the first part of this chapter, we learn how to access directories in the Web environment. In the second part of this chapter, we take what we have learned in the first part to build a sample application.

There are several techniques for using directories in the Web environment:

• LDAP URLs: This is the most straightforward way to use directories. Some languages have functions that produce new LDAP URLs; in other languages, you have to code the URLs by hand. We have seen LDAP URLs in the previous chapters; now we will learn how to use them.

• Web applications: Web applications are applications executed on behalf the Web server. Such applications are better known as CGI scripts, which use the common gateway interface (CGI) to execute an application.

• Application servers: You can access a directory over the HTTP protocol without a Web server. The most popular implementation is Tomcat, available from the Apache foundation.

• Gateways: Another way of accessing a directory via the HTTP protocol is to use a gateway. There are a number of ready-to-use gateways available, the most famous of them being web500gw. But gateways can do much more than access a directory. We will look at these possibilities later in this chapter.

• Web-server authentication: Web servers allow you to protect certain pages with userID and password to control access to these pages. It is possible to let the Web server authenticate users against a directory, thus reducing the number of passwords on the intranet. This involves one further step versus a single sign on.

• Preprocessors: Preprocessors are interpreters that read the Web pages before sending them to the user. The most popular preprocessor is PHP, but Perl can also be used to perform this function. Java server pages and active server pages are further examples where an engine executes code embedded in HTML (hypertext markup language) pages on behalf of the Web server.

We will review each of these topics in the following sections. As always, our choice of products reflects our bias for applications that are as platform independent as possible. Thus, we will not consider Macintosh- or Microsoft-specific solutions. However, all of these techniques work on most platforms supporting Internet/intranet functionality. The same philosophy underlies all of these solutions, so once you have tried one solution, you will easily become familiar with the others.

---