BigAdmin System Administration Portal
Community-Submitted Article
Print-friendly VersionPrint-friendly Version
This content is submitted by a BigAdmin user. It has not been reviewed for technical accuracy by Sun Microsystems, though it may have been lightly edited to improve readability. If you find an error or would like to comment on the article, please contact the submitter or use the comment field at the bottom of the article. Community submissions may not follow Sun trademark guidelines. For information on Sun trademarks, please see http://www.sun.com/suntrademarks/.
 
 

Configuring IBM WebSphere Process Server With OpenDS as an LDAP User Repository

Sachin Krishna Telang, October 2008

Introduction

This article provides a step-by-step procedure for configuring IBM WebSphere Process Server (WPS) 6.0.2.0 with OpenDS version 1.0.0 as an LDAP user registry. The steps mentioned in this article have been tested using IBM WebSphere Integration Developer 6.0.2.2. For configuring the LDAP registry, I used Apache Directory Studio v1.1. The information can be applied to configure any LDAP server.

Note: The procedure in this article was tested on a machine running Microsoft Windows XP Professional with Service Pack 2.

Here's a sample LDAP Data Interchange Format (LDIF) file named users_and_groups.ldif.txt. Please save the file without the .txt extension.

This article covers the following topics:

Configuring OpenDS

Following are the steps to configure OpenDS with IBM WebSphere Process Server for an LDAP user repository.

1. If OpenDS is not already installed, download OpenDS and install it. Accept the default configuration (dc=example, dc=com) with root user cn=Directory Manager.

2. To set up the users and groups using Apache Directory Studio for OpenDS, first download Apache Directory Studio.

3. To set up the Apache Directory Studio connection to the OpenDS LDAP server, do the following:

a. In the Connection dialog box's Network Parameter tab, enter the information shown in Figure 1.

You can enter any value in the Connection name field.

Figure 1

Figure 1: Connection Dialog Box's Network Parameter Tab
(Click to Enlarge)

b. In the Authentication tab, enter the information shown in Figure 2.

Select Simple Authentication as the authentication method. For Bind DN or user, select cn= Directory Manager, which is the default root that is configured when OpenDS is installed.

Note: If you select Anonymous Authentication as the authentication method, then you can only view the LDAP entries, not edit them.

Figure 2

Figure 2: Connection Dialog Box's Authentication Tab
(Click to Enlarge)

c. Click Check Authentication to verify the connection.

This should establish a connection to your LDAP server and display the Directory Information Tree (DIT) in the left panel of the LDAP browser.

Setting Up Users and Groups in the LDAP Repository

Figure 3 illustrates the simple hierarchy in the LDAP registry that is used in this article.

Figure 3

Figure 3: Registry Hierarchy
(Click to Enlarge)

In the supplied users_and_groups LDIF file, members are added to the myGrp and adminGrp groups from ou=people.

Some LDAP entries for User (uid):

dn: uid=sactel+userpassword=sactel,ou=people,dc=example,dc=com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
cn: Sachin
sn: Telang
uid: sactel
userPassword: sactel

Note that the uid entries are created with objectClass=intetOrgPerson.

LDAP entries for group myGrp:

dn: cn=myGrp,ou=groups,dc=example,dc=com
objectClass: groupOfNames
objectClass: top
cn: myGrp
member: uid=wps+userpassword=wps,ou=people,dc=example,dc=com
member: uid=sactel+userpassword=sactel,ou=people,dc=example,dc=com

Note that the groups are created with objectClass=groupOfNames. You can also create groups with groupOfUniqueNames. Users are added as members with the member attribute.

Default root entry:

dn: dc=example,dc=com
objectClass: organizationalUnit
objectClass: dcObject
objectClass: top
dc: example
ou: example.com

This entry is not included in the provided LDIF file, because it is assumed that your base distinguished name (DN) is dc=example, dc=com. If that is not the case, then the provided LDIF file cannot be imported as is. New entries have to be created, or you can simply edit the LDIF file to match your base DN.

With Apache Directory Studio, you can either import the LDIF file or create new entries from scratch.

Figure 4 shows the dialog box for creating a new entry in Apache Directory Studio. You need to select the required objectClass and fill in appropriate values.

Figure 4

Figure 4: New Entry Dialog Box
(Click to Enlarge)

Configuring IBM WebSphere Process Server With the OpenDS LDAP Server Settings

Note: If you are using IBM WebSphere Application Server (WAS), you might notice a slightly different look and feel, because I used IBM WebSphere Process Server (WPS) 6.0.2, which is based on WAS -ND 6.0.2.17. However, conceptually, everything is the same.

1. Enable Global Security as follows (refer to Figure 5):

a. Click Global Security in left pane of the admin console to go to where you can configure WPS security.

b. Select Enable Global Security.

c. Select Lightweight Third Party Authentication (LTPA) as the active authentication mechanism.

d. Select Directory Access Protocol (LDAP) for the active user registry.

e. Click LDAP to configure the OpenDS LDAP server-related specific values.

Figure 5

Figure 5: Enabling Global Security
(Click to Enlarge)

2. Enter the following values to configure the LDAP user registry, as shown in Figure 6:

  • Server user ID and Server user password -- Any user and password, but this user has to be a valid user in the LDAP registry. That is the reason you will see WPS added in the previous LDAP registry structure. Once this configuration is set, you will have to log in.
  • Type -- Custom.
  • Host -- localhost (if the LDAP server is installed on the same system).
  • Port -- 389 (default, if you have not changed it).
  • Base distinguished name (DN) -- dc=example, dc=com, in our case.

Leave everything else as the default value.

Figure 6

Figure 6: Configuring LDAP User Registry
(Click to Enlarge)

3. Click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings and choose the settings that are especially important for OpenDS (refer to Figure 7):

Note: The advanced LDAP user registry settings are crucial, because once WPS establishes a connection to the LDAP server, the search for users and especially groups is controlled by these filter values. So be careful, or else you will end up getting authentication failures, such as WPS SECJ0129E, and have no clue about what is wrong.

a. Change User Filter to (& (uid=%v)(objectclass=inetOrgPerson)), since, in our case, users are created with objectclass=inetOrgPerson, as mentioned previously.

Object Classes defines the data structures that stores specific data. These structures are defined as part of the standard schema files that come with the OpenDS installation. For example, inetOrgPerson can be found in 00-core.ldif, which is located in the <openDS Install Dir>\ config\schema folder.

b. Change Group Filter to (&(cn=%v)(objectclass=groupOfNames)), since you are using objectclass=groupOfNames for creating the groups myGrp and adminGrp. You can also use objectclass=groupOfUniqueNames, if you configured groups in the LDAP server using this object class.

Figure 7

Figure 7: Choosing Important Settings for OpenDS
(Click to Enlarge)

c. Test the filters in Apache Directory Studio by creating a new search and replacing %v with values that exist in the LDAP server. Copy and paste the filter string (& (uid=sactel)(objectclass=inetOrgPerson)) in the Filter Editor. Refer to Figure 8 and Figure 9.

This action should fetch a valid value. If it doesn't, you need to debug this string until you get a satisfactory value. Apache Directory Studio Filter Editor provides a key for your LDAP search queries. Most likely, objectClass supported by the LDAP server will have to be entered correctly.

Figure 8

Figure 8: Testing Filters by Creating a New Search
(Click to Enlarge)

Figure 9

Figure 9: Filter Editor
(Click to Enlarge)

d. In the WPS console, keep the default values for User ID Map and Group ID Map. Or, if you are using different attributes for user ID and group ID, then replace the values accordingly.

e. Ensure that Group Member ID Map reflects groupOfNames:member, because this will identify users to groups. If the object class value does not match the object class in the group filter, authorization might fail with the WPS exception SECJ0129E even after groups are correctly mapped to security roles.

This step helps you map the security roles to the LDAP groups in J2EE applications. If you are using groupOfUniqueNames, then this filter value should be groupOfNames:member.

4. Select Global Security -> Authentication Mechanism -> LTPA to navigate to the screen where you set the Lightweight Third Party Authentication (LTPA) password (shown in Figure 10).

Since we are using LTPA authentication, we need to set the password. Any valid password that is entered is used for encrypting and decrypting LTPA keys.

Figure 10

Figure 10: Setting LTPA Password
(Click to Enlarge)

Testing a Java 2 Platform, Enterprise Edition (J2EE) Application

Testing a J2EE application is beyond the scope of this article. However, once you build your own simple web application, you need to have a security configuration with roles defined and mapped to LDAP groups in deployment descriptors.

Here is sample code for IBM WebSphere Process Server ibm-application-bnd.xmi (used for binding). Notice that securityRole1 is mapped to group myGrp, and myGrp is defined as groupOfNames in the OpendDS LDAP repository.

<?xml version="1.0" encoding="UTF-8"?>
<applicationbnd:ApplicationBinding xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:applicationbnd="applicationbnd.xmi"
xmi:id="ApplicationBinding1">
  <authorizationTable xmi:id="AuthorizationTable_1>
    <authorizations xmi:id="RoleAssignment1">
      <role href="META-INF/application.xml#SecurityRole1"/>
      <groups xmi:id="Group1" name="myGrp"/>
    </authorizations>
  </authorizationTable>
  <application href="META-INF/application.xml#Application_ID"/>
</applicationbnd:ApplicationBinding>

About the Author

Sachin Krishna Telang has over 10 years of IT experience and has worked on various integration technologies, including IBM WebSphere MQ, WebSphere Enterprise Service Bus, and Microsoft BizTalk Server. The author is working with Tata Consultancy Services (TCS) in India as an Application Architect and is part of the SOA project initiative.

Acknowledgments

WebSphere screen shots reprinted courtesy of International Business Machines Corporation, copyright 2008 International Business Machines Corporation.

Microsoft product screen shots reprinted with permission from Microsoft Corporation.

The information and links on this page have been provided by a BigAdmin user. The submitter is solely responsible for such information and links. Sun is not responsible for the availability of external sites or resources, and does not endorse and is not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. Sun will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss caused by or in connection with use of or reliance on the information posted here, or goods or services available on or through any external site or resource.
 
 

Comments (latest comments first)

Discuss and comment on this resource in the BigAdmin Wiki

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


BigAdmin
  
 
BigAdmin Upgrade Hub