25
Tue, Jun
3 New Articles

Using LDAP for an E-business User Registry

Commerce - Other
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

When you are designing e-business applications, you must decide how and where to manage an application’s user information. One management method is via a repository called a user registry. In this article, I will investigate using the Lightweight Directory Access Protocol (LDAP) directory included with OS/400 V4R3 (and later) for this purpose. I will show you that introducing a JavaBean as an accessor to an LDAP server enables Java Server Pages (JSPs) and servlets to use a user registry. I will also explore the use of the XML standards to structure data that is interchanged between Web site components.

 

What Is a User Registry?

 

A user registry is simply a place where information about users is kept. The information may be collected via Web-based applications or internal corporate applications. This information may be used by applications for authentication, marketing purposes, or corporate telephone books. The user registry data is kept in a repository that may be implemented using text files in a file system, tables in a database, or in a directory, as I’ll discuss.

 

A Web Site Example

 

For my example, I’ll discuss a fictional Web site for a local pet store site that provides information about pets available for adoption by local customers. Site visitors register before viewing the information about available animals. The Web site’s implementation registers visitors by using a Web browser-based form and a server-side Web application to store this information in a user registry. The user registry’s repository is an LDAP directory, which is a directory in the DB2 UDB for iSeries 400 (DB2 UDB) database that is accessible using LDAP.

Implementing the user registry in the LDAP directory on the iSeries or AS/400 provides the following potential options for the Web site’s use of the user registry:

• HTTP servers, such as the HTTP server for iSeries 400 and now the Apache HTTP Web server, can be configured to use an LDAP directory when authenticating Web users. By configuring the HTTP server to use the LDAP directory-based user registry, visitors can be restricted to selected Web pages.


• Web application servers, such as the IBM WebSphere Application Server for iSeries 400, can be configured to use an LDAP directory when authenticating Web users. By configuring a Web application server to use the LDAP directory-based user registry, visitors can be restricted to specific functions or operations provided by the Web site.

• Since LDAP directories are hierarchical, you can maintain multiple user registries in the same LDAP directory, but they are in different directory partitions or branches of the hierarchy. You can also organize the structure of each user registry based on information entered by the visitor.

• OS/400 directory services provides LDAP standard utilities for extracting information from the directory. Both workstation- and OS/400-based utilities can query for information about Web site visitors for marketing purposes.

• Since most Web browsers are LDAP-enabled, you can view the contents of the user registry directly from a browser. For example, the following URL would display the contents of the pet store’s user registry stored in the LDAP directory on the system called myiSeries400:

Ldap://myiseries400:389/cn=Visitors,ou=UserRegistry,o=PetStore??sub

• Changes to the visitor registration form require corresponding changes to the user registry’s schema or data definition. Later in this article, you’ll see how easy it is to make these changes to the LDAP directory. Changes can be made by either editing the LDAP server’s schema files in OS/400 V4R3 and V4R4—or, starting in OS/400 V4R5, changes can be made while the LDAP server is running, either by a command line utility or by using a GUI.

 

Implementation Overview

 

In this section, I’ll look at some of the technologies used in the implementation of the Web site and show how they fit together in the implementation. The implementation is based on the following guidelines:

• Provide an introduction to various technologies used to implement server-side Web applications. A partial implementation is provided showing the use of HTML, JSPs, servlets, JavaBeans, LDAP, and available OS/400 technologies working together to implement a simple Web site.

• Provide a separation of various components. This separation allows for reuse of components, ease of implementation using specialized skills, and faster enhancements. The implementation closely follows the well-known Model-View-Controller (MVC) framework. As its name suggests, it is made up of three components.

• The model is responsible for the underlying data and transactions that can be associated with it. This is the business logic. In the example implementation, the model is composed of JSPs and servlets.

• The view is responsible for displaying the data. In the example implementation, the view is the Web browser.


• The controller is responsible for decoupling the interactions between the model and the outside world. This is the interaction control and users need have no knowledge of how the View works. In the example implementation, the controller is composed of JavaBeans, Java Naming and Directory Interface (JNDI), and an LDAP server.

• Provide a means for data interchange between components. The implementation uses XML, HTTP, and LDAP for data interchange between various components.

Figure 1 shows both the components of the implementation and a simple function flow. In the sections that follow, I’ll discuss the components, technologies, and the flow.

 

Component Overview

 

On the workstation, the Web browser is the only component present. Since this is a server- side implementation, no data or HTML files are stored on the workstation. For the server- side implementation, the following components, listed by technology, are implemented on the iSeries 400:

• JSPs—The UserRegistration JSP provides the presentation logic by building the HTML form used for visitor registration. JSPs are text files stored in the AS/400 Integrated File System (AS/400 IFS) and used by the IBM WebSphere Application Server when a Web browser references a URL that contains the name of the JSP.

• Servlets—The UserRegistration servlet provides the presentation logic for processing the registration form’s data. The servlet is invoked by the IBM WebSphere Application Server when the form is submitted because the form’s action URL references the servlet.

UserRegistration separates the presentation and business logic. The servlet transposes form data into XML and invokes the UserRegistry Bean.

• JavaBeans—Implementation consists of two JavaBeans, UserRegistry and LDAPBean, that implement the business logic. Together, these JavaBeans implement the accessor to the user registry data stored in the LDAP directory. Since JavaBeans provide access to the user registry, the Web site’s JSP and servlet developers are not involved with working with an LDAP directory. At this time, the UserRegistry Bean is invoked only by the UserRegistration servlet, but in the future, expect additional JSPs and servlets to use this Bean to access the user registry.

IBM’s LDAPBean can be used to access LDAP directories using JNDI. JNDI consists of Sun Microsystems’ API and IBM’s JNDI service provider. Use LDAPBean as is, and implement all user registration specifics in the UserRegistration Bean.

• LDAP—For Web site visitor information, instead of using HTTP session information stored as cookies on the workstation, use an LDAP directory for centralized management.

Use of an LDAP directory allows more control and options for using the information about Web site visitors, as discussed earlier.

Two of the LDAP components, JNDI and the LDAP server, are provided with OS/400 and implement the data management of the business logic. JNDI interacts with the LDAP server using LDAP (protocol). The LDAP server’s data repository is the local OS/400 UDB DB2 database.


 

Implementation Flow

 

Before diving into the implementation details, I’ll take a look at the simple flow implemented so far for this pet store’s Web site by following the steps shown in Figure 1 (page 43).

1. The JSP UserRegistration was invoked by a URL reference to the JSP. This reference was probably from a New Visitor link on the Web site’s home page. This link was processed by the browser, which passed the reference to the OS/400 HTTP Web server, which then passed the reference to the OS/400 application server, IBM WebSphere Application Server, which then invoked the JSP. The JSP built a simple form allowing users to register information about themselves and then returned the form to the Web browser.

2. When the visitor clicks on the form’s Submit button, the data is sent to the UserRegistration servlet. UserRegistration extracts the form data and structures it into an XML document using an XML schema specific to the Web site. Refer to my sidebar
“Configuring LDAP as an E-business Registry: Additional Implementation Details” atwww.midrangecomputing. com/mc for more information on how this is accomplished. For the pet store Web site, user information is first converted in an XML document using this XML schema. This provides for structured data to be interchanged between the server- side components of the Web site.

3. The Web site is implemented using the UserRegistry Bean, which provides a set of simple operations for JSPs and servlets to use when accessing the user registry. The UserRegistration servlet invokes the add method of UserRegistry Bean to add the visitor’s information to the user registry. The visitor’s information is then passed as a structured Directory Services Markup Language (DSML) document.

4. The UserRegistry Bean’s add method parses the DSML document and invokes the LDAPBean Bean requesting a directory entry to be created.

5. LDAPBean uses JNDI to request the LDAP server to add a new user to the user registry. LDAPBean hides many of the details of using JNDI such as connecting to the LDAP server, formatting input data, and handling responses.

6. The LDAP server creates the directory entry by using DB2 UDB interfaces to update the OS/400 database.

 

Updating the LDAP Schema

 

An LDAP server uses an LDAP schema to identify the attributes and object classes allowed when creating directory entries. In support of the user registry, you’ll need to enhance the default LDAP schema shipped with OS/400 directory services so that additional attributes can be used when creating directory entries for the users. Most of the attributes needed for visitor information are already defined and contained in the object class iNetOrgPerson, an object class defined by an Internet standard and shipped with most LDAP servers.

To manage the visitor information in the OS/400’s LDAP directory, add one more attribute, animalInterests, and the additional object class, AFVisitor, containing this new attribute. Methods for modifying the schema vary depending on your version of the LDAP server, which corresponds to the OS/400 release. IBM recommends enhancing the existing schema by adding only new attributes and object classes and not modifying the existing definitions.


For OS/400 V4R3 and V4R4, the LDAP Version 2-compatible schema modifications are applied to text files stored in the iSeries IFS. Attribute changes should be appended to the end of /qibm/userdata/os400/dirsrv/ UsrAt.txt. Object class modifications should be appended to the end of /qibm/userdata/ os400/dirsrv/UsrOC.txt.

The following code shows the changes added to UsrAt.txt to define one additional attribute called animalInterests, with a syntax of case ignore string (cis), a maximum length of 256 bytes, and normal access control permission:

attribute animalInterests cis animalInterests 256 normal

The changes to be added to UsrOC.txt to define the AFVisitor object class that allows the optional attribute animalInterests are as follows:

objectclass AFVisitor allows animalInterests

For OS/400 V4R5, the LDAP Version 3-compatible schema modifications are applied by one of the following methods:

• Use the Directory Management Tool (DMT), a workstation-based Java application. DMT is useful for making a small number of dynamic changes to an LDAP schema. Refer to the Download and Installation section for information on installing DMT. Once installed, DMT can be launched as follows: Start/Program/IBM SecureWay Directory/Directory Management Tool.

• Modify LDAP server’s schema text files as mentioned earlier. Note that this requires restarting the server after changes are made.

• Use OS/400 Operations Navigator to import the schema modifications while the LDAP server is down. The schema modifications must be defined in a text file in LDAP Data Interchange Format (LDIF).

• Use the ldapmodify utility from a workstation command line, OS/400 command line, or OS/400 Qshell command line. The schema modifications must be defined in a text file in LDIF. The command from OS/400 Qshell would be as follows:

ldapmodify -d -w -f

Note that when using ldapmodify from the OS/400 command line, the text file must be located in the AS/400 IFS and the -h (hostname) and -p (port number) options are not required. Figure 2 shows the LDIF file to modify the schema. LDAP Version 3 requires an object identifier (OID) to be included in the schema. For this example, a text string is used to represent the OID of the new attribute and the new object class.

 

User Registration Servlet

 

The UserRegistry servlet is invoked by an action of the visitor registration form. The servlet uses XMLTransform’s methods to convert the form’s data into an XML document, and then it transforms the XML document into a DSML document. The DSML document is then passed to the UserRegistry Bean’s add method to update the user registry with the new visitor’s information. UserRegistry dynamically creates and returns an HTML page with the results of the registration to the Web browser.


 

UserRegistry Bean

 

UserRegistry is a nonvisual JavaBean specific to the user registry. It provides properties that allow JSPs and servlets to customize a user registry. For example, setUserRegistryParentDN() allows a servlet to override the user registry’s default location in the directory hierarchy. The UserRegistry servlet uses the add method of UserRegistry to add new users. After setting several properties, UserRegistry Bean invokes LDAPBean’s add method to add a user. UserRegistry’s event listener receives events from LDAPBean, translates the events into messages, and sets a status property.

 

Working Together

 

The examples in this article demonstrate many of the newest Internet technologies available from an iSeries that can work together to maintain a Web site’s user registry in an LDAP directory. These examples can be expanded to provide additional user management facilities, such as updating existing visitor information. JSP and servlet developers will find it much easier to work with a user registry through the use of XML to structure data and JavaBeans as accessors. For additional implementation details and Installation and Configuration instructions, be sure to read the sidebar “Configuring LDAP as an E- business Registry: Additional Implementation Details” on the MC Web site at www. midrangecomputing.com/mc.

 

REFERENCES AND RELATED MATERIALS

 

• IBM HTTP Server page: www.as400.ibm.com/products/http/httpindex.htm

• IBM WebSphere page: www.as400.ibm.com/websphere

• iSeries 400 Directory Services (LDAP) Web page: www.as400.ibm.com/ldap

• XML Bible. Elliotte Rusty Harold. New York, New York: Hungry Minds, 1999

• Zvon XSL Tutorial Web site: www.zvon.org/HTMLonly/XSLTutorial/Books/Book1/index.html

WORKSTATION AS/400

Presentation Web Browser Pages

Register JNDI

XSL

Presentation Logic

JSPs and Servlets

UserRegistration.jsp

UserRegistration.class

Business Logic JavaBeans

LDAPBean UserRegistry Business Data LDAP Directory

LDAP Server User Registry

1

2

5

4DSML LDAP


http

Figure 1: Upgrade your Web site user registry using XML, Java applications, and an LDAP directory.


3

6

XML

Schema

dn:cn=schema
changetype: modify
add: attributetypes
attributetypes: ( animalInterests-oid NAME 'animalInterests' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
ibmattributetypes: ( animalInterests-oid ACCESS-CLASS normal LENGTH 256 )

Dn:cn=schema
Changetype:modify
add: objectclasses
objectclasses: ( AFVisitor-oid NAME 'AFVisitor' SUP top AUXILIARY MAY ( animalInterests ) )

Figure 2: Personalize your Web site with visitor-specific information using LDIF files to make schema modifications.


BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: