Netegrity SiteMinder

Performance Planning and Tuning

Netegrity Technical White Paper

Published: August 8, 2003

1
 Page 2

TABLE OF CONTENTS
EXECUTIVE SUMMARY......................................................................................................................................... 3
INTRODUCTION....................................................................................................................................................... 4
STEPS TO TUNE PERFORMANCE ....................................................................................................................... 4
PLAN AND DESIGN INFRASTRUCTURE ........................................................................................................................ 4
Scenario ................................................................................................................................................................ 4
Policy Design ........................................................................................................................................................ 6
Capacity Planning................................................................................................................................................. 7
MEASURING SITEMINDER PERFORMANCE ................................................................................................................. 8
Tools...................................................................................................................................................................... 8
CONFIGURING AND TUNING SITEMINDER FOR PERFORMANCE .................................................................................. 9
Web Agent and Policy Server Interaction ............................................................................................................. 9
Number of Connections .................................................................................................................................... 9
Number of Threads ......................................................................................................................................... 10
Caching ............................................................................................................................................................... 10
Agent Resource Cache .................................................................................................................................... 11
Agent Session Cache....................................................................................................................................... 11
Caching Anonymous Users............................................................................................................................. 12
Policy Server Caches ...................................................................................................................................... 12
Cache Sizing Example .................................................................................................................................... 12
User Directories.................................................................................................................................................. 13
Persistent Sessions .............................................................................................................................................. 14
Password Services............................................................................................................................................... 14
Auto Authorization .............................................................................................................................................. 15
Cookie Encryption............................................................................................................................................... 15
Logging ............................................................................................................................................................... 15
Auditing............................................................................................................................................................... 16
SCALING SITEMINDER TO MEET ENTERPRISE NEEDS .............................................................................................. 16
PERFORMANCE ENHANCEMENTS IN SITEMINDER 5.5 .............................................................................................. 17
CONCLUSION ......................................................................................................................................................... 17
APPENDIX A: PERFORMANCE TUNING WORKSHEETS ............................................................................ 18
APPENDIX B: TESTING ENVIRONMENT........................................................................................................ 19

Figure 1: SiteMinder "Block"..........................................................................................................................3

Figure 2: ApplicationScenario .......................................................................................................................5
Figure 3: Application Usage Model ...............................................................................................................5
Figure 4: Network Sniffer Placement.............................................................................................................8
Figure 5: Login Scenario for Password Services ........................................................................................14
Figure 6: Scaling of Processors ..................................................................................................................16

Table 1: Rule Table .......................................................................................................................................6

Table 2: Factors in Thread Settings ............................................................................................................10
Table 3: Ignore Query Data Example..........................................................................................................11
Table 4: Directory Round Robin Example ...................................................................................................13

Netegrity SiteMinder Performance Tuning

 Page 3

Executive Summary
This technical white paper provides an approach to “tuning” Netegrity SiteMinder. The goal is to
improve web application response times, ultimately resulting in:

• Better customer satisfaction

• High employee productivity
• Reduced costs, associated with lower hardware requirements

The methodology uses best practices from previous and current SiteMinder deployments. This
paper demonstrates how to determine an expected capacity for an application. It defines a set of
components, which will be referred to as a SiteMinder “block”. A block is a logical combination of
optimized SiteMinder and dependent components that could include:

• Web servers with agents

• Policy servers
• User directories
• Policy stores
• Supporting software and hardware, such as load balancers

The block is the atomic unit of a SiteMinder deployment. By increasing the number of blocks, one
can scale an enterprise, while maintaining a known configuration and throughput. Add hardware
uniformly across SiteMinder blocks and test to determine the new throughput. Redundancy can
be built into a single block, and failover can be maintained between multiple blocks.

This document emphasizes tuning blocks through configuration, increasing performance without
added hardware. The document references a financial scenario throughout, for examples of
cache sizing, policy design and directory operations. Figure 1 shows an example of a SiteMinder
block.
Figure 1: SiteMinder "Block"

Netegrity SiteMinder Performance Tuning

 Page 4

Introduction
Tuning middleware products such as SiteMinder to meet high enterprise availability and
performance standards can be a challenging endeavor. Netegrity SiteMinder provides a variety
of means of tuning a deployment to perform well in its environment. The first step is to plan
ahead with performance in mind. Refine requirements, model applications for user load, and
decide how to implement access control policy. Careful testing and measurement follow
planning. This includes identifying the bottlenecks, refining the parameters and scaling the
environment to eliminate the bottlenecks.

Steps to Tune Performance

• Plan and Design infrastructure to meet functional and performance requirements.

• Measure test results to build metrics.

• Configure and tune the different components – continue testing to optimize settings.

• Scale components to extend throughput.

Plan and Design Infrastructure

Planning involves all the preparation required to move SiteMinder from initial deployment into
production, as well as determining security policy and how it will be implemented. Sometimes,
added functionality can compromise performance. For instance, adding password services
requires multiple write operations to user directories. Determine whether all users, or only a
subset, should be subject to a password policy. Vigilant planning throughout the design and
maintenance stages will prevent expensive problems later on. Ensure that all requirements are
clearly understood, to avoid placing unnecessary performance constraints on the system to
enforce a non-existent policy or policies. The following scenario is used as an example
throughout this document.

Scenario

ABC Bank is planning to deploy SiteMinder. The company has 100,000 users in three directories:
customers, employees and partners. Figure 2 shows the application scenario.

Netegrity SiteMinder Performance Tuning

 Page 5

Figure 2: Application Scenario

ABC Bank expects more than half its users to log in to its portal application within the first fifteen
minutes of the workday, starting at approximately 9:00 AM. Users access the application at
various times throughout the 24-hour period. Figure 3 shows the application usage model.
Figure 3: Application Usage Model

0.7

0.6
Moving Average
Percentage of Users

0.5

0.4

0.3

0.2

0.1

0
00

00

00

00

00

0
:0

:0

:0

:0

:0

:0

:0
0:

2:

4:

6:

8:

10

12

14

16

18

20

22

Time of Day

A common name (cn) user attribute response must be returned upon authentication. The
company expects each employee to access a series of twenty pages after login. Password
services are required for the Employees directory only. The Uniform Resource Locators (URLs)
include encrypted query parameter values that are assumed to be different for each user who
accesses the application. The index.html page is an anonymous page that does not require
login. HTML forms-based authentication will be used for the protected pages.

Netegrity SiteMinder Performance Tuning

 Page 6

Policy Design

Policy design can significantly affect performance. Determine how many unique URLs need to be
protected on the policy server, and determine the layout of policies before implementing them.
SiteMinder binds users to resources through rule-based policies. Authentication and session
information is governed by SiteMinder Realms. A resource field is associated with each realm
and with every rule the realm contains, which together form the effective resource. Each resource
field is important in the way that searches are performed, which affects performance.

Realms, Rules, and Responses. The policy server uses the resource defined in the realm
properties to determine whether or not the resource is protected. The larger the number of
realms, the longer it will take the policy server to determine whether or not a resource is
protected. The granularity of authentication schemes or session values may drive realm and
subrealm requirements, but try to combine realms, if possible. Large numbers of rules for any
single realm can slow authorization decisions. The policy server must read all rules within the
realm, regardless of whether or not it finds a match. Evaluate the number and types of
responses applied to each rule. Static response types will be faster than user attribute
responses, which are faster than User DN attribute responses. For the ABC Bank scenario
defined above, policy design should reflect the requirements. As shown in Table 1, two realms
with three rules can manage this application: Two action rules and one OnAuth rule, all with
wildcard (*) resources.
Table 1: Rule Table

Realm
Auth Scheme Rule Resource Action(s) Response(s)
Resource
* GET, POST None
/bankapp HTML Forms
* OnAuth HTTP_CN
/bankapp/index Anonymous * GET None

Evaluate the need for authentication and authorization rules such as OnAuth and OnAccept. It
may be better to bind responses to an OnAuth rule than an action rule, so that the policy server
does not return the response for every unique resource. Do not create an OnAccess rule just to
bind the response to, however. Consider binding to an action rule, if the response is needed on
each request. Disable processing of authentication and authorization events for realms that do
not require OnAuth or OnAccess rules using the Advanced tab of the realm properties dialog box
in the policy server user interface. This is advantageous, performance wise, because it prevents
authorization logic from being performed twice for each realm, even if there are no authorization
rules contained in the realm.

Policy Objects. Bind users to rules using attributes of the distinguished name (DN),
organizational unit (OU), organization (O), or the special SiteMinder reserved word “All”. This is
more efficient than binding via user search expressions, because no directory searches will be
required to resolve membership during the authorization phase.

For the ABC Bank scenario, three separate policies will be created:

• The Anonymous Policy will contain the rule for /index.html. Separating this policy will prevent
heavy anonymous user load from affecting protected content.

• The OnAuthentication Policy will contain the OnAuth rule. An HTTP header response
containing a user attribute will be bound to the OnAuth rule in this policy. The response is
applied to the OnAuth rule to prevent the response from firing for each GET action.

Netegrity SiteMinder Performance Tuning

 Page 7

• The Action Rule Policy will contain the GET/POST rule for all other resources.

Nomenclature. Agent names can make a difference in performance – using the fully qualified
domain name of the host for the agent identity name can improve throughput on agents other
than Microsoft Internet Information Server (IIS). For IIS, consider using the IP address for the
agent identity name.

Capacity Planning

A good approach is to calculate the number of expected authentications and authorizations per
second and, combined with the number of reads and writes to the directory, extrapolate the
necessary infrastructure to support these metrics. For the ABC Bank scenario, the page to login
ratio is twenty to one (20:1). Based on the number of users, the maximum expected number of
1 2
logins would be 67 per second . Thus, the maximum authorization rate is estimated at 1333 per
second.

User Directory. Calculate the number of requests to the user directory, with the following
guideline for authentication:

• One search per user directory to disambiguate the user

• One bind/select to verify the user credential
• One search/query for each Policy bound to an OnAuth rule
• One search to return response attributes
• One write/update for password policy per user directory enabled for password services

For each authentication in the ABC Bank scenario, the breakdown will be as follows:

3 searches to disambiguate the user (for three user directories)

1 bind to verify the user’s credentials
1 search to check Policy for the OnAuth rule
1 search to retrieve the user attribute response
1 write to update the password field for the Employee directory for password services

The total number of expected searches per second would be 333 or five per login attempt. The
ratio of reads to writes for the directory would be five to one for the Employee directory. Perform
similar calculations for authorization:

• One search/query per Policy that includes a GET or POST rule for a given resource
• One search/query per Policy that includes an OnAccess rule for a given resource
• One search to return response attributes

Because we have only one policy governing web requests, there will be only one search per
login. ABC Bank can expect a total of 1333 searches per second, one per authorization. Had an
authorization rule (OnAccess) or response been required in the ABC Bank scenario, the policy
server would have had to perform one or two additional searches per request. Subsequent
searches for authorizations can be minimized through the user authorization cache. Execute a
capacity planning exercise, to isolate the directory server and test it for performance using the
expected load.

Network. The network should support at least 100 megabytes per second, full duplex.

1
60% of 100,000 users over 15 minutes converted to seconds (100,000*.6/15)/60
2
Assumes one authorization per minute per user during peak usage - 67 logins per second times
20 pages

Netegrity SiteMinder Performance Tuning

 Page 8

Co-Location. For each deployment, try to keep agents, policy servers, and user stores in the
same physical location. The next best option is to keep the policy server co-located with the
agents. Caching will help mitigate the physical separation of the policy server and the user and
policy stores. Do not place the policy server and user store on the same physical box, as I/O,
memory and CPU contention could result. Use load balancers and SSL accelerators in front of
the server farms to shorten the response time between the client and web server.

Resources. A resource for performance tuning is the SiteMinder Policy Server Management
Guide. Appendix B of this guide provides several helpful hints to tune user directories and UNIX
platforms. Monitor the Netegrity support site for security advisories and performance related
fixes. Tech notes are a good source for information concerning third party interaction, such as
with directory servers.

Measuring SiteMinder Performance

Proper measurement of all operations is key to understanding where bottlenecks might exist
within the system. Metrics are derived statistics that can reflect how portions of the infrastructure
are performing. Netegrity provides various tools to help gain accurate numbers. Testing is
expensive, so plan tests to maximize the return on investment. Understand the expected results,
and track ongoing tests for errors and anomalous results. The performance test environment
should be representative of the production environment.

Avoid using traditional performance metrics, such as CPU usage, as the sole determining factor
for tuning a SiteMinder deployment. The machine the policy server is running on could be at a
very low CPU usage under load, but this does not guarantee that optimal performance will result.
Instead, measure round trip times between each pair of components to identify where bottlenecks
exist.

Tools

Network sniffers. Sniffers can provide excellent insight into the size and content of the request
for unencrypted data without affecting test results. Numerous vendors provide products for
tracking performance from client to server, including backend processes. Sniffers can provide
alerts to extra packets being sent, long delays between load balancing, and redirection
technologies that logs alone cannot capture. Place the sniffer between the client and the server
on the client-side hub, if the network is setup on a switched hub configuration. Figure 4 shows an
example of how to place a sniffer in the network.
Figure 4: Network Sniffer Placement

Netegrity SiteMinder Performance Tuning

 Page 9

One can place a sniffer at different points in the network to look at different types of packets and
inspect for erroneous behavior.

The SiteMinder OneView Monitor can provide metrics on requests handled by session and
resource caches, as well as average times for authentication and authorization calls.

SiteMinder Test Tool can be used to emulate a Web Agent, thereby allowing isolation of the
policy server. The SmTest interface can simulate multi-threaded concurrent agent requests
without caching against the authentication and authorization services on the policy server. This
does not include any auditing or administration load.

Customized tools and scripts can be built using the Agent API or the Command Line Interface
(CLI) driven by Perl to emulate agent behavior.

Directory server utilities can be used to simulate policy server calls to the directory server or
database to isolate query lags. Use rsearch from Sun’s Directory Resource Kit to create load on
iPlanet directory server; use ldapsearch to perform single queries or batched calls to LDAP
servers to isolate the directory server. Most relational databases provide SQL analyzers to
analyze response time.

Configuring and Tuning SiteMinder for Performance

Sometimes, you can achieve better performance by changing configuration settings in SiteMinder
agents and policy server. Configuring SiteMinder should be the first option, before adding
hardware, in improving performance. It is an iterative process to determine which combination of
settings provides the best performance results in each environment. A worksheet listing
configuration parameters and metrics that affect SiteMinder performance is included in Appendix
A. This section discusses guidelines on tuning through configuration.

Web Agent and Policy Server Interaction

Compare the policy server response time to the agent using the RequestTimeout value in the
agent configuration file, WebAgent.conf, by comparing logs. For 5.x Agents, this parameter is
located in the Host Configuration Object. If the time from request start to end is greater than the
request timeout setting, the agent will retry its request. Do not lower this value too much, as the
policy server may have to contend with duplicate requests from the same agent for the same
request, which could compound the performance issue. If the time for the policy server to
respond is longer than the default value of one minute, then additional analysis will be required on
the policy server side to determine where the bottleneck exists.

Number of Connections

Determine the number of possible connections between agents and the policy server by
multiplying the number of agents times the maximum number of connections. If this number
exceeds the Maximum Connections parameter value on the policy server, increase the setting.
Login failures could result if there are not enough connections available for each agent. Limit the
number of agent identities. Depending on the version of the agent, each agent identity declared
will create a connection between the Web Agent and each policy server service. Authentication,
authorization, and auditing are all separate services in SiteMinder 5.5 and earlier. The policy
server can utilize three-quarters of the total file descriptors (Solaris) or file handles (NT) for
connections with agents or 32 KB, whichever is lower.

Set the maximum number of connections that a policy server will allow through the Maximum
Connections parameter on the Settings tab of the Policy Server Management Console. The
default value is 256, which may not be optimal. The number of connections that an agent will try

Netegrity SiteMinder Performance Tuning

 Page 10

to open on the policy server is part of the Host Configuration Object for 5.x agents and the
WebAgent.conf file for 4.x agents. The settings that affect the number of connections are
MinSocketsPerPort, MaxSocketsPerPort, and NewSocketStep. The agent will initially open the
minimum number of sockets and increase, as needed, in increments of the step value.

Number of Threads

A new threading model is used in SiteMinder 5.5, allocating threads from a shared pool.
Previously, a separate thread was allocated for each Web Agent connection. Proper settings for
thread maximums vary depending on the application. The primary factors to affect the thread
settings are:

• The performance (latency) associated with the backend directory (user store).
• The number of CPUs in the machine hosting the policy server.
• Policy design, in terms of the number of directory searches (or writes) required to execute a
login or authorization request.

Table 2 shows how these factors contribute to the thread setting:

Table 2: Factors in Thread Settings

Use Higher Thread Setting Use Lower Thread Setting

Factor
If… If…

User Directory User directory is slow User directory is fast with

Performance with high latency low latency

Number of CPUs in Policy Policy Server has 4 to 8 Policy Server has 1 to 2

Server Machine CPUs CPUs

Policy Design: Number of Authorization requires Authorization doesn’t

Directory Searches directory searches require a directory search

Measure maximum thread values for authentication and authorization separately. For the
authentication server, start with the default value for Maximum Threads (found on the Settings tab
of the management console) and adjust to accommodate for slow directory servers or password
services.

The number of threads to specify for the authorization server is largely dependent upon
whether an authorization request has to make a directory server search. If authorizations are
performed without the need for a directory search then consider decreasing the Maximum
Threads setting. If authorizations require a directory search, consider increasing this number until
the maximum authorization rate has been achieved.

Run load tests and monitor the throughput, CPU utilization and thread context switching. The
reason for keeping the number of threads small is to reduce the amount of thread context
switching, which can reduce throughput.

Caching

Caching is defined as keeping a resource in memory locally to prevent a “hop” to a different

component. This section discusses policy server and agent cache parameters and makes

Netegrity SiteMinder Performance Tuning

 Page 11

recommendations for how to size and time cache entries. Ensure that the amount of physical
memory is appropriate for the cache setting. The general rule of thumb is 1GB of memory per
machine. The Web Agent features two caches: session and resource cache.

Agent Resource Cache

The resource cache pairs the requested URLs with:

• The policy server response “IsProtected=<Yes/No>”

• Any response attributes returned from the policy server

Once the IsProtected response is cached, the agent can satisfy another request for the same
resource without going back to the policy server, until the cache entry times out. For example, if
a user requests “/page1.html” and the policy server returns “IsProtected=Yes”, the agent can use
this entry for any user accessing the same resource within the cache entry lifetime. The resource
cache is sized by setting the agent’s MaxResourceCacheSize parameter based on the number of
unique URL resources and response attributes, which are also cached. Setting
MaxReourceCacheSize to “0” will disable the resource cache.

Timeouts for resource cache entries are based on the parameter ResourceCacheTimout. The
agent evaluates a cache entry once it is requested, to determine whether or not the resource was
entered into the cache within the timeout period. If the resource cache entry has timed out, the
agent will update the cache and require another roundtrip to the policy server to reassess
authorization. Setting timeouts too low may limit the effectiveness of using the Web Agent
resource cache. Model the application with a representative user set, and measure the period
between like resources. Figure 3 shows an example of determining the load over time on the
application.

Applications that utilize dynamic URLs may be better off without using the resource cache, since
a requested URL may not ever match one stored in the cache. Enabling the parameter
IgnoreQueryData will help the agent utilize the resource cache by truncating the query data that
entered into the cache. If each URL in the application is different because of varying query data,
enable the IgnoreQueryData parameter. This reduces the number of unique URLs, from the
cache perspective. Table 3 is an example of how a request might be taken from cache when
IgnoreQueryData is enabled:
Table 3: Ignore Query Data Example

URL Stored in Cache Taken From Cache

/bankapp/page1.html?user=johndoe /bankapp/page1.html No
/bankapp/page1.html?user=maryjane Yes
/bankapp/page2.html?user=maryjane /bankapp/page2.html No

Enabling IgnoreQueryData also affects how the policy server evaluates URL resources. If
policies are written based upon query data, then do not enable IgnoreQueryData.

Agent Session Cache

The session cache stores the session ID of a user who has been successfully authenticated for a
resource, for use in future authorization decisions. If the same user accesses another resource in
the same realm during the same session, the agent will not ask the policy server to validate the
user for that resource again for the lifetime of the entry, unless the number of entries exceeds the
maximum session cache size.

Netegrity SiteMinder Performance Tuning

 Page 12

Set the agent’s MaxSessionCacheSize parameter based on the number of users accessing the
application for sustained activity within the cache timeout period. Users that login but make few
URL requests should not be counted toward sizing, as they will probably not make adequate
usage of the session cache. Users that re-login within the timeout period should be counted for
each expected session where activity is anticipated. Users cannot be authenticated from cache.

Session cache entries are only relevant to that particular session and become unusable once the
user logs out. Timeouts are based on the SiteMinder Realm Object session value, which can be
configured through the SiteMinder policy server user interface.

Caching Anonymous Users

If using the anonymous authentication scheme, you may consider caching anonymous users by
setting CacheAnonymous to “YES”. Separate the agent that handles anonymous requests from
agents handling protected resources. This helps prevent frequent flushes from high volumes of
anonymous users affecting resource retrieval from cache for protected resources. Conversely, if
not using anonymous authentication schemes, it may not be necessary to enable user tracking
through the policy server user interface. This tracking mechanism is done through an additional
cookie, which affects performance in writing the cookie to the HTTP response and incurring
network overhead for dial-up connections.

Policy Server Caches

The policy server features three configurable caches:

• Object Store Cache maintains entries retrieved from the SiteMinder Policy Store and can be
preloaded for better performance.

• L2 cache links resources to their associated policy objects and should be sized based on the
number of unique URLs and associated methods that must be evaluated by the policy server.

• User Authorization cache allows the policy server to quickly evaluate which policy belongs to
which user and should be sized to the number of policies times the number of users within
the cache entry lifetime.

Avoid frequent cache flushing through the policy server user interface in a production or
performance test environment – if an authentication policy is changed, the automatic update will
occur within two polling intervals (PsPollInterval). Flushing after non-authentication changes will
degrade performance unnecessarily.

The fewer requests that are processed from Web Agent cache, the more round trips will be
required to the policy server, which will naturally affect policy server caches.

Cache Sizing Example

For the ABC Bank scenario, the recommended session cache size is at least “100000,” to allow
each user an entry in cache, since all are expected to continue browsing after authentication.
The recommended resource cache size is at least twenty per agent, for protection decisions for
the twenty pages accessed by each employee after login. Add a small percentage to each cache
size to allow for mistyped URLs and additional logouts. Cache timeout could be set to sixty
minutes to allow for users accessing the application during the first hour of the workday and to
maximize cache usage.

Netegrity SiteMinder Performance Tuning

 Page 13

If the user authorization cache is enabled for the scenario, the policy server can substantially
decrease the number of directory operations. For subsequent authorizations after login, a
3
properly sized user authorization cache will save 1333 searches, in this example.

User Directories

User Directory configuration has a large impact on SiteMinder performance. The policy server
performs a number of searches, binds, and writes to user directories during authentication and
authorization. SiteMinder 5.5 detects referral server failure earlier than before, triggering a fail-
over event sooner, as a result. Connections to the referral server are preserved so that the policy
server does not have to reacquire for each request.

One tactic to improving performance is to isolate the directory to determine whether the searches
are efficient. Use directory indexing to enhance search results for SiteMinder. Contact the
directory vendor for techniques in optimizing search algorithms through SiteMinder. Design
queries to return manageable sets of users or groups – if you are unable to optimize the query,
set maximum search results to limit large result sets from slowing down the overall performance.
Optimize SQL query schemes for ODBC with SQL analyzers. Make sure performance testing
takes into account other external resources, such as mail servers that could contend for
resources.

Adding too many User Directories in a Policy Domain can degrade performance. When you add
an organization to a SiteMinder deployment, consider combining user directories. The search
order matters, as well, and should be aligned with priorities. If a larger percentage of the
organization that will be accessing the application comes from the customer directory, then the
customer directory may need to be listed first in the search list. However, employees may be the
higher priority, even though more users are contained in the customer directory. Consider
placing the employee directory first, to prevent the policy server from searching the customer
directory before being able to validate the employee. It is worthwhile to evaluate these tradeoffs.

One trick is to establish multiple aliases for the same user directory and declare each alias
multiple times in a round-robin fashion. This trick allows the policy server to perform multiple
searches in parallel fashion to the same user directory. Combine round robin with failover to
provide redundancy. Table 4 shows an example of aliasing directory servers in a round-robin
fashion.
Table 4: Directory Round Robin Example

Directory Mappings Round Robin

Customer Primary cp1, cp2
cp1, cs1, cp2, cs2
Customer Secondary cs1, cs2
Employee Primary ep1, ep2
ep1, es1, ep2, es2
Employee Secondary es1, es2
Partner Primary pp1, pp2
pp1, ps1, pp2, ps2
Partner Secondary ps1, ps2

Using Secure Socket Layer (SSL) between the policy server and LDAP will reduce performance.
Review security requirements to determine whether this is mandatory. Do not place an SSL
accelerator between the policy server and the LDAP user store. The policy server will assume a
single instance of the user directory, which could cause inconsistent writes across multiple user
directories behind the accelerator.

3
(67 logins per second * 20 pages)

Netegrity SiteMinder Performance Tuning

 Page 14

If static IP addresses are available for user directories, use these IP addresses rather than
hostnames when you configure user directories. Although the time to resolve these names is
negligible, Domain Naming Services (DNS) dependencies are removed. This applies for
PolicyServer entries in the Web Agent configuration, as well.

Persistent Sessions

SiteMinder features a persistent session server for name/value pairs that can be used for session
storage and token assertions. Ensure that the session server database engine is not a limiting
factor in authentication operations. Configure the session server to run on a fast I/O subsystem
with an appropriate RAID controller and multiple disk drives. Many of the User Directory rules
apply for the SiteMinder session store too.

Password Services

There is a cost to enabling a user directory to use password policy. The policy server must
tabulate each failed login. Thus, each login causes a write operation to the user directory. LDAP
is typically not optimized for heavy write operations. Unnecessary use of password services can
result in lower ratios of reads to writes and limit performance, when you use LDAP servers for
user directories.

Netegrity conducted tests with two LDAP vendors to provide a comparison for login scenarios
with and without Password Services enabled. All tests were login only with a single realm, and
assumed steady state was reached within ten minutes. Results in Figure 5 are in transactions
per second, where a transaction is from client request to response, measured by the load
generation program. Closing the browser instance ends each session.
Figure 5: Login Scenario for Password Services

Login Scenario

400

350
Transactions Per Second

300

250
Vendor 1
200
Vendor 2
150

100

50

0
Without Password Services With Password Services

A large disparity in performance occurred when password services was enable on both vendor
platforms. Throughput was 35-40% greater when password services was disabled. Enabling
password policies to track logins, without even redirecting the password application, can degrade
performance.

Netegrity SiteMinder Performance Tuning

 Page 15

NOTE: These results are not guaranteed for any environment.

There are workarounds to the issue of password services performance. If only a portion of the
organization requires password services, enable only that portion of the user directory through
the password policy definition. If you are not using a user directory for password services, ensure
that the user profile attributes are cleared in the User Attributes tab of the user directory
properties dialogue of the policy server user interface. Leaving the User Attributes defined could
cause unnecessary write operations to the user store. If SiteMinder is not responsible for
preventing dictionary attacks that require maintaining record of how many times the agent has
been accessed, a write to the directory server can be eliminated by disabling tracking of logins
through the password policy Expiration tab.

Auto Authorization

The Web Agent features the ability to authorize access to file types based on their extensions,
without going through session validation and authorization phases. Add the extension(s) to the
IgnoreExt parameter. Default file types include image files and credential collectors – do not
remove image file types, unless the content is devoid of complex pictures or the pictures
themselves need to be protected. If possible, avoid usage of OverrideIgnoreExt. Enabling this
parameter will disable auto-authorizations for any resource that matches the value of the
parameter, meaning all image files will be checked for protection. Configure URLs so that they
end with known extension types to ensure proper handling by SiteMinder. Also, avoid “double
dots” in the URLs. More than one “.” will prevent the agent from auto-authorizing the resource.

Cookie Encryption

SiteMinder cookie content is encrypted for security purposes. The act of encrypting and
decrypting the cookies is an expensive process in terms of performance. The default Web Agent
behavior is to reissue a session cookie for each validation that occurs, which means one
encryption and decryption per request. Current versions of the Web Agent feature a grace period
(SessionGracePeriod) in which the session cookie is reissued to the browser. Raising the grace
period value can reduce the frequency of cookie encryptions.

Logging

Restrict the use of debug level logging to file and console, for troubleshooting scenarios. File
logging is faster than console logging. When you use logs to determine times, look for dual
asterisks as the separators that define begin and end requests. The following example shows the
endpoints of an isProtected call in a policy server log:

[02/Jul/2003:15:14:24 -0500][2816-I] ** New s3/r1 (IsProtected) from agent '

abcbank'
…
[02/Jul/2003:15:14:24 -0500][2816-I] ** Status s3/r1 : '
'Protected.

Asterisks delimit login and authorize calls. Agent logs have transaction and thread identifiers that
help separate multiple requests to the same agent. Information about what requests were
handled from cache is available in the Web Agent log. Disable all debug logging for any type of
performance testing or production environment. Analyze logs only in an isolated non-test
environment, to troubleshoot or analyze segments.

Netegrity SiteMinder Performance Tuning

 Page 16

Auditing

By default, auditing is asynchronous. It will not delay the response to the agent if writing to the
auditing log or database not complete by the time the authentication or authorization decision is
made. If you select synchronous auditing, auditing becomes a serial portion of the timeline.
Synchronous auditing reduces authentication and authorization performance, as it prevents the
agent from allowing the resource until auditing services have completed. Depending on auditing
services reliability, enabling this feature poses a severe performance risk.

For each service (authentication, authorization, administration and affiliate), administrators can
have all events, rejection events or no events logged to a database repository or flat file. Review
audit policy to determine whether all events or just rejection events are to be tracked. Enabling
the auditing of cached events on the Web Agent (EnableAuditing) can be detrimental to overall
performance if auditing is synchronous, as the agent calls directly to the accounting service on
the policy server.

Scaling SiteMinder to Meet Enterprise Needs

Increase memory to increase the cache size potential for both agents and policy server. The
guideline is at least one gigabyte of RAM per policy server or agent machine. Add memory on
the policy server to improve Java Virtual Machine (JVM) operations such as expression
resolution.

The SiteMinder policy server that has multiple processors can handle more transactions. Figure 6
shows the throughput improvement from a single to a quad processor:
Figure 6: Scaling of Processors

Netegrity SiteMinder Performance Tuning

 Page 17

Environment parameters for these results are included in Appendix B. Solaris and Windows
results were very similar in terms of trend lines.

Data regarding a user session is maintained in a transient cookie in the default configuration. No
state needs to be maintained in between login calls on the server side. Therefore, it doesn’t
matter which policy server handles an agent’s request, assuming that each policy server is
sharing the same policy and key stores.

You can use the round-robin algorithm for clustering policy servers to balance the load required
by agents in the enterprise. Because each policy server is equally weighted, standardize the
specifications of each policy server instance in the cluster to achieve uniform results. Plan
geographical distribution of policy servers. Try not to scatter servers of the same cluster across
different physical locations. Agents will continue to evenly distribute load evenly to remaining
policy servers if one or more of the servers becomes unavailable. Once the policy server
recovers, it assumes its portion of the load without any type of restart on the web server.

Performance Enhancements in SiteMinder 5.5

SiteMinder 5.5 takes Netegrity to a higher level of performance with new features such as
improved user attribute retrieval:

• All the necessary user attributes are retrieved on a first call to user directory
• All required user response attributes are retrieved in one call
• User attributes are cached for the duration of the request

Many of the techniques discussed in this paper are based on technologies that have also been
added to SiteMinder 5.5. Customers have validated that the newer threading model improves the
number of concurrent operations that the policy server can sustain. The ability to cache
responses is making significant differences in the response time of the applications. The
directory utilization in 5.5 reduced the number of queries to the user directory in one case by
75%! By improving performance using the same infrastructure, customers save costs.
Performance continues to be a positive differentiator for Netegrity as the best of breed in identity
and access management.

Conclusion
There is no “silver bullet” configuration that will work best for all environments. Careful planning,
testing and tweaking controlled environments will provide the best answers as to how SiteMinder
should be deployed in an enterprise. Knowing the current and future capacity requirements is
crucial to preparing a infrastructure. Try to configure SiteMinder first, before expending budget
resources to scale the infrastructure. Maintain vigilance in applying fixes. Reassess the
architecture as changes are made. Netegrity is confident that the technology will meet the
highest standards for performance in enterprise access management.

Netegrity SiteMinder Performance Tuning

 Page 18

Appendix A: Performance Tuning Worksheets

Parameter (Web Agent) Run1 Run2 Run3 Run4 Run5 Run6 Run7
maxresourcecachesize
maxsessioncachesize
resourcecachetimeout
requesttimeout
pspollinterval
ignoreext
cacheanonymous
maxsocketsperport
minsocketsperport
newsocketstep
sessiongraceperiod
Parameter (Policy Server)
Maximum Connections (Auth)
Maximum Connections (Az)
Maximum Connections (Auditing)
Maximum Threads (Auth)
Maximum Threads (Az)
Maximum Threads (Auditing)
User Authorization Cache Size
User Authorization Cache Timeout
Object Cache % Preloaded
L2 Cache Size
Audit Authentication*
Audit Authorization*
Audit Administration*
Audit Affiliate*
* Legend: N = None, R = Rejection Only, A = All

Metrics
Login to Page Ratio
Logins per second
Authorizations per second
Searches/sec during auth
Searches/sec during az
Writes/sec during auth
Agents per Policy Server
Network packets/sec
Authentication round trip
Authorization round trip
Client to Agent
Agent to Policy Server
Policy Server to User Store
Policy Server to Policy Store
Policy Server to Auditing Store
Policy Server to Session Server
Credential Collection Redirection

Netegrity SiteMinder Performance Tuning

 Page 19

Appendix B: Testing Environment

Policy Server Machine Sun Fire[tm] V880 Server
CPU 4x 750 MHz Ultra SPARC[tm] III (64-bit)
Memory 8 GB RAM
Disks 4 x 36 GB 3.5" x 1" 10000 RPM FC-AL
disks
Software Solaris 2.8 -
Network 100 MB 100BASE-T
Agents Machine Compaq Evo W4000
CPU 1.7 GHz
Memory 1 GB
Disks Standard
Software Windows 2000 Server SP2 – IIS 5
Network 100 MB (card)
Directory Server Machine Dell 4550
CPU 2.5 Ghz with 512 FSB
Memory 1 GB RAM
Raid Adaptec
Disks 2 x 120 GB Maxtor 8MB cache – Raid 0
Software Iplanet Directory Server 5.1 SP2
Network 100 MB
Load Generation Segue Silk Performer 5.0
Win2K System, (Dual-800Mhz cpu, W2K)
Auth Scheme Basic

Copyright © 2003 Netegrity, Inc. All Rights Reserved.

Trademarks
© 2003 Netegrity, Inc. All rights reserved. Netegrity®, SiteMinder®, IdentityMinderTM and
TransactionMinder® are registered trademarks or trademarks of Netegrity, Inc. All other product names,
service marks, and trademarks mentioned herein are trademarks of their respective owners.

Netegrity SiteMinder Performance Tuning