Library > Articles >

Optimizing performance with WebSphere LDAP Configurations

Sean G Wilbur – IBM Rational, Unleash the Labs
Last Updated: November 2, 2012
Build Basis: Rational solution for Collaborative Lifecycle Management

Summary

When deploying Jazz solutions to WebSphere using a Standalone LDAP registry there are no options for specifying a user or group base. When using a Federated Registry the options are available but may not have been populated. In an environment with a complex LDAP directory structure there is potentially room to optimize this performance by utilizing filters and narrowing the scope of the searches.

Identifying Potential Performance Problems

The first step here is to understand what WebSphere does during a normal user login. This involves 3 major steps, searching for a user by id (login userId passed in), binding to the directory with the user password ( passed in via login ), and finally the group/role lookup to determine the user authorization (a.k.a. roles) at the repository level.

The key piece of this is understanding how the values provided in the ldap connection are used to derive the underlying queries to the Directory server. You can perform these searches in any LDAP browser tool that you are familiar with, the examples below are performed directly on the command line. Here we are listing the default filter configuration for a sample using the inetOrg Schema which will dictate the User and Group objectclass filters3 but this is just one example and the same method applies to other directory providers by modifying the filters.

Below are a few variations of the queries starting with a default with no additional filtering, to a preferred level of filtering. Note these commands are wrapped for clarity and would be called on a single command line. The specific parameters of interest here are the following:

Example ldapsearch4 command for reference.

  ldapsearch -h directory_hostname -D bind_user_distinguished_name -w 'bind_user_pass'   		-b search_base_dn  		filter  		attribute_list_returned
  • Base DN: dc=home,dc=example,dc=com
  • User Filter: (objectClass=inetOrgPerson)
  • User Base DN: ou=users,dc=home,dc=example,dc=com
  • Group Filter: (objectClass=groupOfNames)
  • Group Base DN: ou=groups,dc=home,dc=example,dc=com
  1. Find User “deb” 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=admin,dc=home,dc=example,dc=com -w '***'   		-b dc=home,dc=example,dc=com  		'(&(objectClass=*)(uid=deb))'  		dn
    Improved version: 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=admin,dc=home,dc=example,dc=com -w '***'  		-b ou=users,dc=home,dc=example,dc=com   		'(&(objectClass=inetOrgPerson)(uid=deb))'  		dn
  2. Bind as User “deb” 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=deb,dc=home,dc=example,dc=com -w '***'  		-b dc=home,dc=example,dc=com   		'(&(objectClass=*)(uid=deb))'  		dn
    Improved version: 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=deb,dc=home,dc=example,dc=com -w '***'  		-b ou=users,dc=home,dc=example,dc=com    		'(&(objectClass=inetOrgPerson)(uid=deb))'  		dn
  3. Find Roles for user “deb” (N.B. This is normally the most expensive operation) 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=admin,dc=home,dc=example,dc=com -w '***'  		-b dc=home,dc=example,dc=com   		'(&(objectClass=*)(member=uid=deb,ou=users,dc=home,dc=example,dc=com))'  		cn
    Improved version: 
      ldapsearch -h kablamo.swilbur.us.ibm.com -D cn=admin,dc=home,dc=example,dc=com -w '***'  		-b ou=groups,dc=home,dc=example,dc=com   		'(&(objectClass=groupOfNames)(member=uid=deb,ou=users,dc=home,dc=example,dc=com))'  		cn

Using this guidance as a starting point, you can focus you can analyze the time it takes to process the queries, response times, and if you are interested in finding out more about what is going on under the covers you can take these 3 queries to your Directory Admin to help address your questions. The WebSphere authentication to LDAP is using industry standard practices so there should be no new suprises here and all these directory attributes should already be indexed and highly optimized for read and queries.

Resolving these types of performance problems:

General Guidance

In many cases the performance of the directory is fixed, as noted above Directories are highly indexed and optimized for query and read operations already. Sso our only way to improve the response times here is to provide more focused our search and query requests.

The first way to achieve this is via the filter mechanism, this is available in the avanced properties dialog in the standalone configuration page, and under the Entity Types configuration for a Repository in a Federated Registry. Here we can further specify both the user and group filters that will be applied. Note that these are shown with the special filter that will be populated at runtime, where the value is signified as ‘%v’ so be sure not to remove those. However using the methods outlined above and some assistance from your Directory admins it is possible to do more than just the simple objectClass filters I provided above, and is really only limited by what attributes you have in your Directory, so there can be some other gains to be made there. IBM has related Education Assistant video5 to help here, this is covering the same high-level topics that we are interested in here.

If you are unsure how to proceed here and are seeing delays of more than a second in any of the example LDAP queries above. It is recommended that you contact your Directory team with the above LDAP queries in hand to begin optimizing your filters.

Help for delay with #2

Unfortunately this is as direct a query as you can make, as this has all the information it needs to connect with no additional querying or processsing. If we find that these types of operations are slow, this is a sign of system wide issues with the Directory and we should involve the Directory Admin team to assist. Given the information you produced in #2 you should have sufficient proof that there is a bigger problem here.

Help for delays on #1 and #3

In a Federated Registry, these values are part of the Entity Type configuration, they are empty by default so you can simple add a search base to your PersonAccount entity, and the group search base to your Group entity.

In a Standalone Registry, to resolve a slow user and/or role lookup, there is an additional property available as of WAS 6.11 to provide a more targetted search. These two are lumped together as you get them both really as a package anyway. Using this custom property that can be set on the standalone directory server in the form provided below that will help you specify a group base dn. This will get us to the improved version of query #3 above. 

   Name: com.ibm.websphere.security.ldap.groupBaseDn   Value: ou=jazzgroups,ou=apps,ou=groups,o=dev,o=example.com

By providing this additional parameter we are further specifying the resultant LDAP queries to the directory server to use a targeted group base to search from and can avoid some additional delays that you may incur during the query #3 above to find roles for a given user.

As a side effect now, the base dn no longer being used for both the group and user base, but now really only used during user searches so it can be further specified directly to the desired user base as in the improved version of query #1 above. In this way allowing you to provide a more focused search for both your users and groups.

Copyright © 2012 IBM Corporation

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Feedback
Was this information helpful? Yes No 3 people rated this as helpful.