Introduction

By following the steps outlined below you will be able to:

• Configure the necessary entries in the IBM Tivoli Directory Server to support WebSphere authentication.
• Configure your WebSphere Server to use your LDAP for authentication.

Back to top

Adding WebSphere Roles and Entries to your LDAP Server

If you completed the LDAP set up in the previous article, you have built an LDAP tree structure with Billing Department entries. Although Billy Parker got fired during the course of the first article, he has been hired back into the company by the Billing Department manager Barbara Jensen. By the end of this article you will have seven department member entries in your employee LDAP tree.

Table 1. Billing Department Employees Distinguished and Relative Distinguished Names in LDAP

All of the members in the Billing Department are under the ou=people,dc=ibm,dc=com portion of the LDAP tree. For this article you will add a new container class and two new groups

• cn=roles,dc=ibm,dc=com,
• cn=billingdept,dc=ibm,dc=com,
• cn=billingdeptmgr,dc=ibm,dc=com.

The employees in the Billing Department will be added to the new cn=billingdept,dc=ibm,dc=com group. The only entry in the cn=billingdeptmgr,dc=ibm,dc=com will be the manager of the Billing Department, Barbara Jensen.

Below are excerpts from the LDIF (Lightweight Data Interchange Format) file that you will use to construct the updated LDAP tree. The first is the cn=roles,dc=ibm,dc=com container.

	
dn: cn=roles,dc=ibm,dc=com
objectclass: container
objectclass: top
cn: roles

The two groups, cn=billingdept and cn=billingdeptmgr, have attributes listing their member's distinguished names.

	
dn: cn=billingdept,dc=ibm,dc=com      
objectclass: groupOfNames
objectclass: top
cn: billingdept         
member: uid=c0001,ou=people,dc=ibm,dc=com                  
member: uid=c0002,ou=people,dc=ibm,dc=com      
member: uid=c0003,ou=people,dc=ibm,dc=com      
member: uid=c0004,ou=people,dc=ibm,dc=com      
member: uid=c0005,ou=people,dc=ibm,dc=com      
member: uid=c0006,ou=people,dc=ibm,dc=com      
member: uid=c0007,ou=people,dc=ibm,dc=com     

dn: cn=billingdeptmgr,dc=ibm,dc=com      
objectclass: groupOfNames
objectclass: top
cn: billingdept         
member: uid=c0001,ou=people,dc=ibm,dc=com      

You will also add a new user account for the administration of WebSphere, uid=wsadmin,cn=roles,dc=ibm,dc=com. Another account will be created that will allow WebSphere to bind to the LDAP server, uid=wsbind,cn=roles,dc=ibm,dc=com.

Table 2. Distinguished names for WebSphere role ids in LDAP

Adding entries using IBM Tivoli Directory Server Configuration Tool

At this point you have two ways that you can add entries to your LDAP tree. If you prefer to use a graphical user interface, then stop the LDAP server and navigate to Start => All Programs => IBM Tivoli Directory Server 5.2 => Directory Configuration and launch the IBM Tivoli Directory Server Configuration Tool.

Add to your LDAP the employee and role entries. Select Import LDIF data. Browse to the setup2.ldif file. Select the Remove trailing spaces in Standard Import or Bulkload check box. This is a Standard import. Click the Import button. After the import completes, press Clear results. Then press the Close button. The LDAP server cannot be running when you are importing LDIF data using the Directory Configuration Tool and the suffix dc=ibm,dc=com must be present.

Close the Directory Server Configuration Tool by selecting in the menu bar File => Close.

Adding entries using the Command Line

Execute ldapadd with the input setup2.ldif file from the command line. During the execution the LDIF (Lightweight Data Interchange Format) file adds any missing employee entries. In addition the three new groups are built and the wsadmin and wsbind user ids are added. Two new options have been included in this ldapadd command. The –a option indicates that the default operation is to add an entry. The –c option indicates that the processing should continue on error. The order of the parameters is important. For your LDAP configuration onlycn=root can add or update entries.

 	
ldapadd -a -c -h ldap://<ldaphostname> 
-D "cn=root" -w ibm4root 
-f <ldif_directory_path>setup2.ldif 

Updating the entries using the Command Line

If you used either the Directory Server Configuration Tool or the command line ldapadd, you added new entries to your LDAP tree. However, neither of these commands updated any existing entries. If you did not execute the modifyemployee.ldif in the previous article, then your LDAP does not have the latest telephone numbers and company picture for Barbara Jensen. The ldapadd supports a replace parameter, -r . To update any existing entries with the latest attributes run the following command.

 	
ldapadd -c -r -h ldap://<ldaphostname> 
-D "cn=root" -w ibm4root 
-f <ldif_directory_path>setup2.ldif 

Your LDAP entries should now be ready for use by your WebSphere Application Server.

Back to top

Enabling Security in your WebSphere Application Server

Since the remainder of this article describes the setup of the WebSphere Application Server version 6, you need a development installation of WebSphere Application Server version 6 for this portion. If you want to use a small footprint application server for Windows, install the WebSphere Application Server Express Edition.

Before you change your WebSphere Application Server configuration you should backup your configuration files using the backupConfig utility. Run the backupConfig.bat located in the <websphere install>\bin directory. After you complete the article you can restore the initial configuration using restoreConfig.bat.

If you are using the WebSphere Application Server Express Edition launch the Administration Console by navigating to Start => Programs => IBM WebSphere => Application Server Express v6 => Profiles => default. Click on Administrative console The Administrative console requires the application server to be running.

Once the Administration Console has been launched, login using the user id WAS. From the tree in the left pane, navigate to Security => Global Security. Locate the User registries section and click on the LDAP link.

In the LDAP User Registry section, enter uid=wsadmin,cn=roles,dc=ibm,dc=com for the Server user id. The Server user password is was4me. Of course the Type is IBM Tivoli Directory Server. If you installed your LDAP server on Windows then you can choose either localhost or your server name as the host name. The Base distinguished name (DN) is dc=ibm,dc=com. The base distinguished name is where WebSphere will begin its searches. All the user ids and groups are under dc=ibm,dc=com. The dc=ibm,dc=com distinguished name provides the lowest common denominator for all the relavant branches of the tree. For the Bind distinguished name use (DN) use uid=wsbind,cn=roles,dc=ibm,dc=com with the Bind password of was4me. You have the option of using cn=root and password ibm4root as the bind distinguished name and password. In the "real" world, the owner of an LDAP server is very unlikely to give you the cn=root password. You should get in the habit of sparingly using the cn=root id for routine LDAP functions. Select the Ignore case for authorization checkbox. This is required for LDAP servers. Click the Apply button. You will then be prompted to press the Save link and then the Save button.

Although you do not have to make any advanced LDAP modifications you should be familiar with the LDAP search criteria used by WebSphere. Click on the Advanced Lightweight Directory Access Protocol (LDAP) user registry settings link.

In the first article, the table below was used to show the format of an LDAP search filter. On the Advanced Lightweight Directory Access Protocol (LDAP) user registry settings panel you can see these filters in use.

Table 3. LDAP Search filters

The user filter is set to (&(uid=%v)(objectclass=ePerson)). This means that if you provide WebSphere with a uid attribute such as wsadmin, it will search your LDAP tree starting at the base distinguished name dc=ibm,dc=com for a match. WebSphere is also only searching for ePerson objects. When you configured your LDAP server all of the members of the billing department as well as the two role entries, wsadmin and wsbind, were created as ePerson objects.

The group filter is set to (&(cn=%v)(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=groupOfURLs))). The cn attribute for the two new groups, cn=billingdept and cn=billingdeptmgr fit this search criteria. The cn=roles group is a container class so it does not fall into this search pattern.

Click on the Global Security link in either the navigation tree or the top of this panel to return to the Global Security panel.

Expand the Authentication mechanism and click LTPA (Lightweight Third Party Authentication).

LTPA is an authentication mechanism used by WebSphere for applications. Although you do not need a LTPA to set up WebSphere security for this article, in most cases you will want a LTPA token defined for your production WebSphere server. Enter was4me as the password. Press the Apply button to accept your changes.

Click on the Single signon (SSO) link.

If you use LTPA you should have single sign-on (SSO) enabled. LTPA combined with SSO allows WebSphere to remember the Billing Department member's identity across requests using a cookie. If you don't enable SSO with LTPA, then the WebSphere Application Server must authenticate the user on every request. Make sure that the Enabled checkbox is selected. The Domain name field specifies the domain name for all the single sign-on hosts. For example, if your host name is tirane.ibm.com, you could specify the Domain name to be ibm.com. This would allow your server to share authentication rights with other WebSphere Application Servers in the ibm.com domain. If you use the keyword, UseDomainFromURL, then WebSphere Application Server sets the SSO domain name value to the domain of the host used in the URL. For tirane.ibm.com the generated domain name would be ibm.com. Setting the Domain name is not required for this article. Press the OK button until you return to the Global Security panel.

On the Global Security panel select the Enable global security checkbox. The Enforce Java 2 security checkbox will automatically be selected. Use the drop down list to choose the Lightweight Directory Access Protocol (LDAP) user registry. Make sure that you are using LTPA (Lightweight Third Party Authentication). Click the OK button.

You will be prompted to save your configuration. If any of the values you entered in the LDAP registry section are invalid, you will get an error at this point.

If your configuration is correct, you should log out from the Administrative Console. Restart your WebSphere server. When you logon to the administration console you will now be prompted for both a user name and a password. Enter wsadmin for the user name and was4me as the password. Press the Log in button.

You have completed adding LDAP authentication to your WebSphere Application Server.

Back to top

Conclusion

In this article you learned how to update your existing LDAP entries from the command line. You enabled authentication on your WebSphere Application server using your LDAP server.

Back to top

Download

Information about download methods

Resources

• The IBM Tivoli Directory Server for Windows is available from IBM
  
  
• To learn more about WebSphere Application Server version 6, visit the WebSphere Infocenter site..
  
  
• The IBM Redbook Understanding LDAP - Design and Implementation can provide you with some practical guidance.
  
  
• Get more information regarding the IBM Tivoli Directory Server by participating in Security Management developerWorks forum.
  
  
• The WebSphere Application Server has a lively community in the WebSphere developerWorks forum.
  
  
• Keys Botzum offers a good checklist for securing your WebSphere Application Server WebSphere Application Server 4.0 Security Maxims
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Adding WebSphere Roles and Entries to your LDAP Server
• Enabling Security in your WebSphere Application Server
• Conclusion
• Download
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

Dig deeper into Tivoli on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers