Welcome!

PowerBuilder Authors: Dan Joe Barry, Carmen Gonzalez, Ian Thain, Yakov Werde, Paul Slater

Related Topics: PowerBuilder

PowerBuilder: Article

LDAP with EAServer and PB 8.0

LDAP with EAServer and PB 8.0
By Berndt Hamboeck
Article Rating:
June 1, 2002 12:00 AM EDT
Reads:
 8,398

The Lightweight Directory Access Protocol (LDAP) is for accessing online directory services. It runs directly over TCP and can be used to access a standalone LDAP directory service. Developed in the early 1990s, it defines how a client should access data on the server. It does not specify how the data should be stored on the server.

Most often you'll interact with a server specifically built for LDAP, such as OpenLDAP or iPlanet (now Sun ONE) Directory Server. However, LDAP can become a front end to any type of datastore. Because of this, most popular directory services now have an LDAP front end of some type, including NIS, NDS, Active directory, and even Windows NT domains. For example, if you want to access NT domain information, you can use the Active directory or the NT Sync service available with the iPlanet Directory Server.

What Is a Directory Service?
A directory is like a database, but tends to contain more descriptive, attribute-based information. This information is generally read much more often than it's written. As a consequence, directories don't usually implement the complicated transaction or rollback schemes regular databases use for high-volume complex updates. Directory updates are typically simple all-or-nothing changes, if they're allowed at all.

Directories are tuned to give a quick response to high-volume lookup or search operations. They may have the ability to replicate information widely in order to increase availability and reliability, while reducing response time. When directory information is replicated, temporary inconsistencies between the replicas may be okay, as long as they eventually get in sync.

There are many different ways to provide a directory service. Different methods allow different kinds of information to be stored in the directory, and place different requirements on how that information can be referenced, queried, and updated and how it's protected from unauthorized access, etc. Some directory services are local, providing service in a restricted context (e.g., the finger service on a single machine). Other services are global, providing service in a much broader context (e.g., the Internet).

Global services are usually distributed, meaning the data they contain is spread across many machines, all of which cooperate to provide the directory service. Typically, a global service defines a uniform namespace that gives the same view of the data no matter where you are in relation to the data.

What Is LDAP?
LDAP is a directory service protocol that runs over TCP/IP. The nitty-gritty details of LDAP are defined in RFC 1777, "The Lightweight Directory Access Protocol."

The following section provides an overview of LDAP from a user's perspective.

  • What kind of information can be stored in the directory?
    The LDAP directory service model is based on entries. An entry is a collection of attributes that has a name, called a distinguished name (DN). The DN is used to refer to the entry unambiguously. Each of the entry's attributes has a type and one or more values. The types are typically mnemonic strings, such as "cn" for common name and "mail" for e-mail address. The values depend on which type of attribute it is. For example, a mail attribute might contain the value "admin@bhitcon.net". A jpegPhoto attribute would contain a photograph in binary JPEG/JGIF format.

  • How is the information arranged?
    In LDAP, directory entries are arranged in a hierarchical treelike structure that reflects political, geographic, and/or organizational boundaries (see Figure 1). Entries representing countries appear at the top of the tree. Below them are entries representing states or national organizations. Below them might be entries representing people, organizational units, printers, documents, or just about anything else you can think of.

    In addition, LDAP lets you control which attributes are required and allowed in an entry through the use of a special attribute called objectclass. The values of the objectclass attribute determine the schema rules the entry must obey.

  • How is the information referenced?
    An entry is referenced by its distinguished name, which is constructed by taking the name of the entry itself (called the relative distinguished name or RDN) and concatenating the names of its ancestor entries. For example, the entry for Berndt Hamboeck in Figure 1 has an RDN of "uid=berham" and a DN of "uid=berham, ou=developer, o=myorg, c=US". The full DN format is described in RFC 1779, "A String Representation of Distinguished Names."

  • How is the information accessed?
    LDAP defines operations for interrogating and updating the directory. Operations are provided for adding and deleting an entry from the directory, changing an existing entry, and changing the name of an entry. Most of the time, though, LDAP is used to search for information in the directory. The LDAP search operation allows some portion of the directory to be searched for entries that match some criteria specified by a search filter. Information can be requested from each entry that matches the criteria.

    For example, you might want to search the entire directory subtree below the company mycomp for people with the uid berham, retrieving the surname (sn) found. LDAP lets you do this easily. Or you might want to search the entries directly below the c=US entry for organizations with the string "my" in their name and a fax number. LDAP lets you do this too. The next section describes in more detail what you can do with LDAP and how it might be useful to you.

  • How is the information protected from unauthorized access?
    Some directory services don't provide protection, allowing anyone to see the information. LDAP provides a method for a client to authenticate or prove its identity to a directory server, paving the way for rich access control to protect the information the server contains.

    How Does LDAP Work?
    LDAP directory service is based on a client/server model. One or more LDAP servers contain the data that makes up the LDAP directory tree. An LDAP client connects to an LDAP server and asks it a question. The server responds with the answer or with a pointer to where the client can get more information (typically, another LDAP server). No matter which LDAP server a client connects to, it sees the same view of the directory; a name presented to one LDAP server references the same entry it would at another LDAP server. This is an important feature of a global directory service such as LDAP.

    Let's Do It
    We will download and configure our own free LDAP server under Windows 2000. When it's up and running, we'll add our own entries to the server and see how they look in an LDAP editor. Then we'll create an EJB to access the LDAP server and a PowerBuilder client to add or change values.

    Installing the Free LDAP Server
    First we need a free LDAP server. The OpenLDAP project provides an excellent open source LDAP server for non-Windows platforms, and FiveSight has made a few modifications necessary to compile the server and constituent libraries so that OpenLDAP will run on Windows NT/2000.

    Get the Windows implementation of OpenLDAP at www.fivesight.com/downloads/openldap.asp. The most current version at the time of writing was 2.0.19 (OpenLDAP 2.0.19, with debugging enabled). Don't be confused by the Unix-centric archives. The file can be opened and extracted with WinZip. Simply extract it into a directory.

    Setting Up an LDAP Server

    • Unzip OpenLDAP to c:\OpenLdap
    • Create a directory C:\OpenLdap\openldap-ldbm
    • Configure C:\OpenLdap\slapd.conf so it looks like Listing 1 (changes are marked in bold)
    After configuring we have to start our own LDAP server using a DOS-Box: Slapd -d -1 (the parameter -d 1 enables full debugging) (see Figure 2). I started it using 1 as a parameter. This will trace all function calls. Now that it's up and running, we have to add some predefined values to our server. We'll use an LDIF file to do this.

    An LDIF File
    LDAP Data Interchange Format (LDIF) is a file format used to import and export directory data from an LDAP server and to describe a set of changes to be applied to data in a directory. This format is described in the Internet draft "The LDAP Data Interchange Format (LDIF) - Technical Specification" (see Resources section at end of article).

    The LDIF is used to represent LDAP entries in a simple text format. This section provides a brief description of the LDIF entry format that complements ldif(5) and the technical specification RFC2849.

    The basic form of an entry is:

    # comment
    objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
    MUST ( sn $ cn )
    MAY (userPassword $ telephoneNumber $ seeAlso $ description ))

    Lines starting with a "#" character are comments. The attribute here is called person. Person must have the attributes sn and cn; for example, it may have userPassword.

    Another example is the organization attribute:

    objectclass ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL
    MUST o
    MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
    x121Address $ registeredAddress $ destinationIndicator $
    preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
    telephoneNumber $ internationaliSDNNumber $
    facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
    postalAddress $ physicalDeliveryOfficeName $ st $ l $
    description ) )
    In the file core.schema you can find the aforementioned rules regarding which data can import into our LDAP server.

    In our example, if we want to add a DN of o (an organization), you have to specify (it requires) o and you can add additional attributes like description, userPassword, postalCode, or postalAddress. Remember this is defined in core.schema.

    If we want to add people to our company we have to define the objectclass, cn, and sn, and as additional values we could add description, telephone number, and password. Listing 2 provides the complete ldaif file we'll use with our OpenLDAP installation.

    Create this file in the OpenLDAP installation directory and use the ldapmodify tool from within a DOS-BOX to add this entry to our server.

    ldapmodify -a -x -D "cn=Manager,o=myorg,c=US" -W -f example.ldif

    To verify if the values are really there, use the ldapsearch tool from within a DOS Box:

    ldapsearch -x -b "o=myorg,c=us" "(objectclass=*)"

    ldapsearch -x -b "uid=berham,ou=developer,o=myorg,c=us" "
    (objectclass=*)"

    You'll get back the stored values from your LDAP server.

    As you can see, this output doesn't look nice and we have to work from a command shell to make changes to our directory. A better tool to verify and change the values within our LDAP server is a (free) LDAP browser that can be downloaded from www.iit.edu/~gawojar/ldap/download.html. Configure the Base DN and the DN for the user and the password (you can find all these values in our previously configured slapd.conf file) (see Figure 3). After saving and connecting to the LDAP server, look at our previously imported data (see Figure 4).

    Programming the LDAP Server
    We'll write a PowerBuilder client application that connects to an EAServer installation. Within EAServer we'll have an EJB that connects to the LDAP server and sends results back to the PowerBuilder application.

    The PowerBuilder Client
    We want to write a PowerBuilder application that can:

    • Read and display values from a given DN
    • Change values from a given DN
    • Add new values
    • Test logging on to the LDAP server
    To achieve this we'll use an EJB that we'll call from PowerBuilder. Listing 3 shows the application.

    The scripts behind the buttons look more or less the same. I decided to copy the code from one button to the next. I would never code this way in a real-world example, but I thought this way would be easier for beginners to understand.

    If we look at the button Test Login we can see that there is:

    • A connect to EAServer
    • The lookup for the EJB home interface
    • The creation of the remote object of the EJB
    • The initialization for the parameters we'll pass to the EJB
    • The function call (in this case, for the connect)
    • A MessageBox that shows us success or failure of the authentication
    Here are some hints if you want to develop this example from scratch:
    • Import the CTSComponents package for the exceptions.
    • Look up the Bean class name and the JNDI name using Jaguar Manager by right-clicking your EJB and choosing properties. On the General tab is the information you'll need (at.bhitcon.ldap.LDAPCaller and myLDAP/LDAPCaller in our case) (see Figure 5).
    • When you download and import myLDAP.jar, use Deploy -> EJB on the Package folder in Jaguar Manager.
    • Don't forget to install the newly created package (myLDAP) in your Jaguar server!
    • Refresh the server.
    The Session EJB
    We'll use a session EJB that will do the following tasks:
    • Connect to our LDAP server (with username/password verification).
    • Search the LDAP directory.
    • Add entries to the LDAP directory.
    • Change values in our LDAP directory.
    In the network environment, directory services play an important role. They can provide authentication, access control, and finder services for our application. In Part 2 we'll discuss how the JNDI API allows us to easily use LDAP.

    Resources

  • LDAP specification: www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1777.txt
  • The LDAP Data Interchange Format (LDIF) - Technical Specification: www.faqs.org/rfcs/rfc2849.html
  • Distinguished names (DN): www.umich.edu/~dirsvcs/ldap/doc/rfc/rfc1779.txt
  • Attribute description: ftp://ftp.isi.edu/in-notes/rfc2252.txt

    • Published June 1, 2002 – Reads 8,398
    Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
    Syndicated stories and blog feeds, all rights reserved by the author.

    More Stories By Berndt Hamboeck

    Berndt Hamboeck is a senior consultant for BHITCON (www.bhitcon.net). He's a CSI, SCAPC8, EASAC, SCJP2, and started his Sybase development using PB5. You can reach him under admin@bhitcon.net.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.