***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Typically with COTS applications the vendor will provide instructions as to what software components are configurable to meet a customer’s business needs.  But is it enough to simply understand what components are allowed to be customized?

Depending on the nature of the business the customization can play a significant role in how an application performs and what software components need be tuned.

Some examples of the questions you need to ask yourself and your organization include:

What type of organization are we running the application in?

Is this a banking site where most of the daily activities are dawdling with the exception of pay day when everyone and their significant other wants to see their salaries deposited, thus slowing down down the systems to a crawl?

Is this a high-traffic auction or retail site where customer registrations constantly hammer repositories while  inventories get updated thousands times per minute and the company must account for triple traffic around Chrismahanukwanzakah?

Is this a research site where databases get pounded with complex queries by the Revenge of the Nerds crew?

We at IDMWorks have run into these situations a multitude of times while working with customers.   Many times we see applications get tuned incorrectly or the application is tuned to the correct specifications but the hardware isn’t sufficient enough to handle the required settings (like putting a Smart Car engine in a Mustang).

So for today I would like to promote tuning guidelines for an Identity System, specifically Oracle Access Manager (OAM), and explain how to better tune your application and/or help make better decisions during the design and architecture phase of your project.

Tuning Identity System Searches

For OAM and really any Access Management application, the types of searches that user’s conduct in the directory can significantly affect performance.

For example, Customer Service Representatives in a high traffic call center should not perform a search for a customer with the last name “Smith” while instead searching for the last name “Smith” compounded with the first name to insure a narrowing of the search.  Of course this is common sense and we all know how our user’s practice common sen….um, forget that last line.

So lets force the CSRs to come to our train of thinking.

These steps below will help you to optimize Identity System Searches in the directory:

Restricting the operator use in search

When users conduct a search in an Identity System application, the search bar presents a drop-down list with options for matching the search input with a set of results. These options include the following:

• That contains
• Contains in order
• Equals
• Less than
• Greater than
• Begins with
• Ends with
• Sounds like

The “greater than” and “less than” operations can result in many entries being searched and retrieved. By eliminating these choices, you can improve the performance of search operations. You configure and adjust the search operations in a set of parameter files.

To eliminate the “greater than” and “less than” search operations

1.   To modify the search bar open each of the following files in a text editor (here Install_dir is the directory where Oracle Access Manager is installed):

Install_dir\identity\oblix\apps\userservcenter\bin\userservcenterparams.xml
Install_dir\identity\oblix\apps\groupservcenter\bin\groupservcenterparams.xml
Install_dir\identity\oblix\apps\objservcenter\bin\objservcenterparams.xml
Install_dir\identity\oblix\apps\selector\bin\selectorparams.xml

2.  Find the entry for the ObEnhanceSearchList parameter in each of these files. and edit the entry in each of the files so that it only contains the following parameters:

<ValNameList ListName=”ObEnhanceSearchList” >  <NameValPair ParamName=”OOS” Value=”MOOS”/> <NameValPair ParamName=”OSM” Value=”MOSM”/> <NameValPair ParamName=”OEM” Value=”MOEM”/> <NameValPair ParamName=”OBW” Value=”MOBW”/> <NameValPair ParamName=”OEW” Value=”MOEW”/> </ValNameList>

4. Modify the query builder by opening the following file in a text editor:

Install_dir\identity\oblix\apps\querybuilder\bin\querybuilderparams.xml

5. Then edit the element ObQBOperatorsList to have only the following values:

<ValList ListName=”ObQBOperatorsList” >  <ValListMember Value=”CND_CON”/> <ValListMember Value=”CND_DNC”/> <ValListMember Value=”CND_EQ”/> <ValListMember Value=”CND_NEQ”/> <ValListMember Value=”CND_PRE”/> <ValListMember Value=”CND_NPR”/> <ValListMember Value=”CND_BW”/> <ValListMember Value=”CND_EW”/> </ValList>

Require the user to enter a minimum number of characters in a search field

1.       To specify the minimum number of characters users must enter in the primary search bar open the following file in a text editor (where Install_dir is the directory where Oracle Access Manager is installed):

Install_dir\identity\oblix\apps\common\bin\oblixappparams.xml

2.       Set the value of the searchStringMinimumLength parameter to the minimum length of the string that users can input (as illustrated in the following example):

<NameValPair ParamName=”SearchStringMinimumLength” Value=”3″/>

Restricting the Number of Entries Returned on a Search

You can set a limit on the number of elements that can be returned as the result of a search in an OAM.  This limits the effect that a search can have on performance.  You can configure the maximum number of search results that are returned from the directory server on the Size Limit parameter for the directory server instance profile.

For example, if you set the value of this parameter to 1,000, a maximum of 1,000 entries can be returned in the search results. The default value of 0 indicates that an unlimited number of results can be returned.

You can specify different size limits for different directory server profiles. For example, you can configure a size limit of 0 (unlimited) for the directory server instances that your valued Identity System Administrators use and you can configure a limit of 1,000 for the directory server profiles that are used by those lowly demented end users such as Customer Service Reps (wait, did I just write that?) .

To restrict the number of entries returned on a search

1.       From the Identity System Console select System Configuration.

2.       On the System Configuration page select Directory Profiles.

3.       Select the link for the directory server profile to which you want to add a database instance (the Modify Directory Server Profile page will appear).

4.       Scroll down to Database Instances and select the database instance you wish to configure (the Modify Database Instance page appears).

5.       Configure the Size Limit parameter to indicate the maximum number of search results that can be returned from the directory server.

Create Thread-Safe Plug-Ins

Both the Access Server and Identity Server are multithreaded. Thus when writing  custom code  ensure that all Identity Event plug-ins are thread-safe. This recommendation also applies to Identity Event plug-ins.

Consider Pooling Identity Servers

It is a good practice to use at least two Identity Servers running in a pooled primary configuration. Pooled primary means using multiple Identity Servers that run as primary servers with one or more WebPass instances connecting to the primary Identity Servers.

You can use separate Identity Servers as secondary servers when using the  pooled primary approach. If you have only two servers, a pooled primary configuration is recommended over using one primary and one secondary server. When running a pooled primary configuration it is best to use identical but separate hardware for the Identity Servers.

Advantages of pooled primary mode

• Increased performance through load balancing
• Increased availability through multiple servers
• Automatic failover

Disadvantages of pooled primary mode

• The cost of additional hardware.

• Additional system configuration (if there are no secondary servers each primary server needs to be sized to handle the total expected load if the other primary servers are unavailable).

Configure Identity Servers from a File System Level

Identity Server configuration and stylesheet files must be identical on all servers. This applies to all configurations that use multiple Identity Servers. You should configure all Identity Servers from a file system level, that is, ensure that all directory and file system structures are identical.

Configure Identity Servers to Use 3 GB of Virtual Memory

On Windows, if the Identity Server causes high memory utilization, the system can crash. You can configure an Identity Server to use 3 GB of virtual address space even if 2 GB addressing is already enabled in the boot.ini file.

By default the virtual address space of Identity Server is limited to 2 GB. You can configure a 3GB switch in the Boot.ini file to allocate 3 GB of virtual address space to an Identity Server that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address an additional 1 GB of virtual address space beyond the usual 2 GB limit.

The following example shows how to add the 3GB parameter in the Boot.ini file to enable Identity Server memory tuning:

[boot loader]  timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT=”????” /3GB

Well class, that is all for today, I hope this helps you with your deployment of Oracle Access Manager.

Look for additional discussions on tuning Workflows, Access Server and the Directory in the near future.