A new edition of the Identity Management Design Guide with IBM Tivoli Identity Manager Redbook was released last week. This version updates the guide to include the new features with ITIM 5.1.

The abstract:

Identity management is the concept of providing a unifying interface to manage all aspects related to individuals and their interactions with the business. It is the process that enables business initiatives by efficiently managing the user life cycle (including identity/resource provisioning for people (users)), and by integrating it into the required business processes. Identity management encompasses all the data and processes related to the representation of an individual involved in electronic transactions.

This IBM® Redbooks® publication provides an approach for designing an identity management solution with IBM Tivoli® Identity Manager Version 5.1. Starting from the high-level, organizational viewpoint, we show how to define user registration and maintenance processes using the self-registration and self-care interfaces as well as the delegated administration capabilities. Using the integrated workflow, we automate the submission/approval processes for identity management requests, and with the automated user provisioning, we take workflow output and automatically implement the administrative requests on the environment with no administrative intervention.

This book is a valuable resource for security administrators and architects who wish to understand and implement a centralized identity management and security infrastructure.

To generate reports from ITIM, you must first run a report data synchronization (commonly called just 'data sync'). This pulls data from the LDAP server and places it within reporting tables in the ITIM database allowing for standard relational queries to be made against the LDAP data. In addition to the LDAP data, access control information (ACI) is calculated to ensure that non-admins are restricted from seeing report data to which they are not entitled.

Calculating the ACI data can take a while and there are two ways to speed it up:

The first way to speed up ACI calculations during a data sync is to ensure you're at the latest ITIM maintenance level. ITIM 5.0 IF17 introduced performance improvements that decreases the ACI time of a data sync by half. ITIM 5.1 included this performance boost at GA.

The second is to disable ACI calculations during data syncs if you're not using them. If Administrators are the only people accessing the reporting data then ACIs are not evaluated and thus are not needed. Additionally reports generated via external tools like Tivoli Common Reporting (TCR), Cognos, or Crystal Reports do not make use of the ACI data thus calculating them is just wasting CPU cycles. You can disable the ACI calculations by editing adhocreporting.properties and and setting the availableForNonAdministrators to false. Note that this will prevent non-admins from generating reports from within ITIM. Disabling ACI calculations in ITIM 5.0 requires IF23 or later. ITIM 5.1 included this capability at GA.

It's often handy to be able to get a list of index differences between two TDS installations. Usually this is between a Production (or pre-Production) environment and a Quality Assurance environment, but not always.

The following is a quick and dirty way to do this and assumes a copy of both environments ITDS instance 'etc' directory (contains the ibmslapd.conf and schema files) are on the local machine as follows:

• Prod: ./prod/etc
• QA: ./qa/etc

First, get a list of all attributes on both systems:

# grep ' NAME' ./production/etc/* | cut -d' ' -f4 | sed "s/'//g" > ./all_attributes.production
# grep ' NAME' ./qa/etc/* | cut -d' ' -f4 | sed "s/'//g" > ./all_attributes.qa
# cat all_attributes.production all_attributes.qa | sort -u > all_attributes

Now get the attribute indexing details using the perfanalyze_indexes.pl script from the ITIM Tuning Scripts:

# perfanalyze_indexes.pl -i all_attributes -a -d production/etc > production.indexes
# perfanalyze_indexes.pl -i all_attributes -a -d qa/etc > qa.indexes

Then diff them (I use gvimdiff, a regular diff works too)

# gvimdiff qa.indexes production.indexes

It's not perfect, but it's a good way to sanity check the indexes between two environments.

A new version of the ITIM Virtual Service Adapter (VSA) has been released. This version has the following new features:

• Reconciliation: VSA now supports reconciliation. This is accomplished by creating an LDIF on the machine with the TDI Dispatcher. When a reconciliation occurs the accounts in the LDIF are returned. By changing the reconciliation query different LDIFs on the TDI Dispatcher system can be used.
• Simulated delay for adapter operations: The VSA provides a configurable options to introduce delay in account operations (add, modify, delete) as well as during reconciliation (initial delay and per-account delay). This allows better simulation of actual endpoints.

See also the article Testing IBM Tivoli Identity Manager using Virtual Services in the ITIM wiki.

The fourth edition of the ITIM 5.0 and 5.1 Performance Tuning Guide was released today. This update includes:

• support for ITIM 5.1 - most of the tunings are the same as for 5.1 although some of the tunings were incorporated into 5.1 directly
• improving report data synchronization performance
• tuning suggestions for the ITDI Dispatcher to avoid OutOfMemory errors for provisioning to large numbers of services
• a slew of missing indexes that were in place for DB2 but not for Oracle/MS SQL -- note that these only apply to ITIM 5.0 as they were added to the ITIM 5.1 DBConfig tool
• a formalized version of the information I presented in my ESI caching post
• updated recommendations on WAS PMI settings (WAS L2 recommends that it be disabled entirely unless troubleshooting a specific issue)
• additional recommendations on improving recon performance

The eighth edition of the ITIM 4.6 Performance Tuning Guide was released today. This update includes:

• improving report data synchronization performance
• tuning suggestions for the ITDI Dispatcher to avoid OutOfMemory errors for provisioning to large numbers of services
• a slew of missing indexes for the ITIM DB that were in place for DB2 but not for Oracle or MS SQL
• additional recommendations on improving recon performance

A new version of the ITIM Performance Tuning Scripts is available.

This version introduces a new directory (itimIndexes) that contains DDL files for creating missing indexes for various ITIM versions.

In addition, Oracle support is provided by the following scripts:

• oracle_dumpDBCfg.sql - dumps database parameter configuration values for review by support and the performance team
• oracle_dumpDBStats.sql - dumps database-level statistics information out for review by support and the performance team
• oracle_dumpSQLStats.sql - dumps SQL statistics information out to a file for processing by perfanalyze_dynamicsql.pl
• oracle_exportDDL.sql - creates a DDL file of all tables, indexes, and views in the database for review by support and the performance team

Windows versions of the collectITDSData.bat and collectDB2Data.bat have been added. These do not package up the resulting data into a tar file like their Unix siblings however.

perfcheck_tunings.pl does some sanity checking against a WAS collector.sh output such as to output the JVM size information and any PMI configuration problems. I hope to expand this in the future.

The ITIM_Performance_Scripts_Documentation.pdf has been updated with (brief) information about the new files.

This is a follow-up to my previous post regarding Firefox 3.5 support for ITIM 5.x.

In addition to Firefox 3.5, Internet Explorer 8 is not officially supported with ITIM 5.0 or 5.1 although early testing seems to indicate that it functions just fine.

If your organization needs, or will need, support for IE 8 or FF 3.5, please contact your IBM account team, lab advocate, or IBM support and request a copy of the OSDB Certification Request Form.

Just a heads up that Firefox 3.5 does not fully work with the ITIM 5.0 and 5.1 Console UI. Most things appear to work except for radio buttons and checkboxes that have AJAX events attached to them. For example, when changing the password for a user the "Generate a password for me" radio button is selected by default; trying to select "Allow me to type a password" radio fails. Similarly when creating a role the radios to toggle between a Static and Dynamic role do not function.

Support is aware of this issue and Firefox 3.5 support will likely be implemented in a future fix pack. Until then continue to use one of the supported browsers.

In my last post about the importance of HTTP compression for ITIM Console performance I put forth this statement:

Use of the HTTP server and HTTP compression is recommended in front of single-server ITIM nodes because of the improved UI responsiveness for the Console. The HTTP server can reside on the same machine as the ITIM server itself in such a configuration.

Today I'll give you another good reason to use the HTTP server in front of even single-server systems: Edge Side Include (ESI) caching.

Without a front-end cache, when a client makes a request for a static image it does so directly to WebSphere Application Server. WAS in return serves up the image using the File Serving Enabler. In doing this WAS has to expend some CPU and memory resources inside the JVM to service this request. Overall this is less than ideal — why not serve the static content directly from the web server? You can disable the File Serving Enabler and let the HTTP server service static content but that requires manually keeping the content deployed in the EAR in sync with the content on the web server. Instead it would be nice if there were just a caching later in the web server itself.

Enter ESI caching. The IBM HTTP Plug-in that does the load balancing of client GUI requests in a clustered environment also has built-in support for ESI which does page- and fragment-level caching. While ESI does a lot more than just caching static content, for the purpose of this discussion lets focus specifically on it's ability to cache images, Javascript, and CSS files.

If you're using the IBM HTTP server with the Plug-in in front of your WAS clusters the odds are good you're using ESI already. Out of the box, the HTTP Plug-in has ESI enabled with a cache size of 1024kb (1mb) and a cache timeout value of 300 seconds (5 minutes). Enabling ESI and the size of the cache are set from within the plugin_cfg.xml file with the following lines (if the lines aren't present -- what is listed below is assumed as the default):

   <Property Name="ESIEnable" Value="true"/>
   <Property Name="ESIMaxCacheSize" Value="1024"/>

With ESI when a client makes a request for a static image, the Plug-in checks to see if it's already in the ESI cache and if so serves it up directly. If not it goes off and queries the WAS server for the image and the File Serving Enabler returns it to the Plug-in which caches it and returns it back to the client. This offloads the request for static content onto the IBM HTTP server and lets WAS focus on the dynamic content.

The size of the static content (images, Javascript, and CSS) served up from the ITIM Console GUI is around 825k. For the Self-Service GUI it's around 550k. This means that if the bulk of your traffic is either one or the other -- the default 1MB cache is more than adequate to completely cache the static content. If you have lots of both kinds of traffic (such as end-user servicing their own requests for password changes in addition to helpdesk personnel doing account maintenance) you might want to bump up the cache size to 1536k or 2048k. Caution must be used when increasing this value because there is one ESI cache per HTTP process so the total memory used by the ESI cache is ESI_cache_size*HTTP_processes.

Another knob available for tuning is the cache timeout. By default any entry is only valid in the ESI cache for 5 minutes. After this time has passed the data is expired and a subsequent request will be passed back to WAS. In a busy environment with new users accessing ITIM every few minutes, this will result in a hit to WAS every 5 minutes. Because ITIM static content doesn't change once every 5 minutes, you can change the timeout value to something much higher — like once a day. This is done by adding a parameter to the JVM command line for the application server running ITIM:

-Dcom.ibm.servlet.file.esi.timeOut=3600

If you go this route you'll want to bounce your IBM HTTP server after installing an ITIM fix pack to ensure that the ESI cache is cleared for the rare case where a fix pack changes static content.

More in-depth reading about caching in front of WAS applications can be found in the developerWorks article Static and dynamic caching in WebSphere Application Server V5. While the article is dated for WAS V5, the concepts are applicable to WAS V6 and V7 as well.