Linux command tutorial

Lightweight Directory Authentication Protocol (LDAP) is often promoted as a means to leverage an organizational directory as a principal registry for WebSphere authentication and authorization. Advantages include the capability to configure single sign-on across application servers, enabling additional organizational applications, centralized user administration, multimastered replication across authentication sites, and flexible, extensible data formats - not to mention that LDAP is a vendor-neutral protocol and API backed by IETF. This begs the question of how to implement WebSphere security through LDAP.

This two-part series presents a simplified example of how to configure WebSphere Application Server version 5.0 to use IBM Directory Server v5.1 as its user registry for J2EE application user authentication and role-based authorization. This registry enables the ability to configure single sign-on capability across applications residing on multiple WebSphere Application Servers and Lotus Domino servers. By the end of the second part of this article, you will understand how to create an LDAP user registry from scratch, and will have gained an understanding of how to incorporate an existing LDAP user directory as the user registry for securing WebSphere J2EE applications.

Required Software Components

WebSphere Studio Application Developer, version 5.0 (hereafter called WebSphere Studio), will be used to create and host the example using the embedded Web Sphere Test Environment v5 as the target application server.

IBM Directory Server v5.1 will host the LDAP directory service. This directory server, available as a free download from IBM (www.-3.ibm.com/software/network/directory/ server/download), includes a copy of IBM DB2 UCB v8, used to contain the underlying directory information.

The example was written for a Microsoft Windows NT/2000/XP platform, but the principles used apply to any supported platform. The directory server and the application server are often installed on separate machines or even separate platforms, if available.

Create Directory Information

You are starting from scratch, so you first need to design a directory information tree (DIT) and then create an import file that contains entries that conform to it.

DIT DESIGN

The J2EE application users will authenticate themselves through Web Sphere Lightweight Third Party Authentication (LTPA). A security token granted by LTPA can propagate to other WebSphere and Domino servers that participate in single sign-on. The user registry can be an LDAP directory or a custom implementation. LDAP has the advantage of being an IETF (Internet Engineering Task Force) standard protocol. Its implementations can be distributed as multimaster replicated directories. There may support additional clients such as organizational white pages applications or service locators.

The example involves LTPA configured to use a scratch-built DIT for its user registry. An LDAP directory stores information in nodes. In this directory, each user has a node that stores information unique to her or him. Each group has a node that maintains a list of unique members. You will be able to set optional attribute values at will to track an organization's personnel information for use by other applications.

WebSphere LPTA uses LDAP to map authorization roles to users and groups. Therefore the DIT needs to contain a set of user entries. In addition it needs a set of groups such that each group entry refers to a subset of users that belong to that group.

The literature generally agrees that a shallow directory hierarchy is less sensitive to organizational changes than a deep hierarchy. The sample organization name is Rogers60, located in the United States. The J2EE application will be constrained by user and admin roles, but it is easy to add more application roles later as the need arises. The example subtree of the LDAP hierarchy is defined by a suffix so that the users and groups fall under that suffix (see Figure 1).

Each person node under the ou=people node contains the object classes person and ePerson. These object classes include optional attributes that can fulfill most anticipated personnel directory requirements. The ePerson object class defines the uid and userPassword attributes that WebSphere will use for authenticating a request having a supplied user ID and password.

Each ou=groups node contains the groupOfUniqueNames object class, which specifies a multivalued attribute named uniqueMember. A group entry will use the value list of this attribute to reference the distinguished name (DN) of each user in a given group. WebSphere will use this information to check group membership for a role mapped to a DIT group.

LDAP Interchange Format File

LDAP uses an import and export file format, called LDAP Interchange Format (LDIF), that is composed of name-value pairs that define and populate nodes in the DIT. The first line for a node entry must define its DN. The definitions of the node's object classes and attributes follow the DN. Each line starts with a nonblank, unless it continues the previous line. The definition of an entry ends with a blank line. A "#" begins a comment line. The LDIF format is easy to understand, as the example will illustrate.

Create an LDIF file to initially populate the directory for the example. A DIT resembles a file directory tree, so begin by creating higher-level nodes that contain lower-level nodes, and then create the contained nodes. The DIT root will be the directory suffix o=rogers60,c=us, which will be defined later using the IBM Directory Server Configuration Tool. Thus the LDIF file begins at the o=rogers60 node. Next, it defines the people and groups nodes. Finally, it populates the people and groups nodes with data nodes.

Use an editor such as VI or Notepad to create the text file named rogers60.idif, shown in Listing 1. Double-check your work and then save the file in a work directory. We will import the LDIF file into the directory server later.

Notice that the final user node has a uid attribute set to "was". This defines the user account to be used by WebSphere when security is enabled. A sampling of optional attributes, such as telephoneNumber from object1Class ePerson, illustrates how this directory could be extended as a personnel directory. Option attribute values can be added at any time.

Notice that the userPassord attribute is not encrypted. The default access control defined for the userPassword attribute makes it invisible to queries by anonymous LDAP clients. The directory server stores it using imask encryption, meaning that the value is encrypted on the disk but sent in clear text on the network. WebSphere will search the directory as an authenticated privileged client, so the password will be received in clear text. An SSL connection will prevent snooping or undetected alteration of the data on the network.

IBM Directory Server v5.1

Insert the IBM Directory Server v5. 1 CD-ROM into the CD drive in the target machine. Choose all options, including the GSKit, DB2, and WebSphere - Express. If you already have DB2 7.2 or DB2 8, the directory server will offer to use it. GSKit is needed for securing the directory with SSL. The WebSphere - Express Server hosts a Webbased directory administration Web application.

DEFINE THE ADMINISTRATOR DISTINGUISHED NAME

After installation there is a forced reboot, followed by automatic invocation of the IBM Directory Server Configuration Tool. The administrative distinguished name is used to bind to the directory with administrative privileges. Set this DN by carrying out the following steps:

1. Click the Administrator DN tree node.

2. Ensure that the administrator DN is cn=root. This is a DN that has administrative privileges. Its user can see and update anything in the directory.

3. Set the password to secret.

4. Set the confirmation password to secret.

5. Click OK.

CONFIGURE A DATABASE

Use the following steps to define the DB2 database container for the LDAP information:

1. Click the Configure Database tree node.

2. Name the database ldapdb2

3. Supply user ID db2admin or your existing DB2 administrative user ID.

4. Enter the DB2 user password.

5. Create the database.

Create the LDAP Directory

The directory server has not yet been started. Use the IBM Directory Server Configuration Tool to set directory suffixes and import the LDIF file.

SET DIRECTORY SUFFIXES

The directory root DN o=rogers60,c=us refers to the relative tree root node in the DIT. Carry out the following steps to set the suffixes for the DIT:

1. Click the Manage Suffixes tree node.

2. Set the Suffix DN field to o=rogers60,c=us.

3. Press the Add button to add the suffix.

4. Press OK.

IMPORT THE LDIF FILE