Performance Planning & Tunning

1

Performance Planning and Tuning

Netegrity Technical White Paper

Published: August 8, 2003

Netegrity SiteMinder

Page 2

Netegrity SiteMinder Performance Tuning

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

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"

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.

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

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0:00

2:00

4:00

6:00

8:00

10:00

12:00

14:00

16:00

18:00

20:00

22:00

Time of Day

Per

cent

age

of U

sers Moving Average

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.

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

Resource Auth Scheme Rule Resource Action(s) Response(s)

* 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.

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 logins would be 67 per second1. Thus, the maximum authorization rate is estimated at 13332 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

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

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

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

Factor Use Higher Thread Setting If…

Use Lower Thread Setting If…

User Directory Performance

User directory is slow with high latency

User directory is fast with low latency

Number of CPUs in Policy Server Machine

Policy Server has 4 to 8 CPUs

Policy Server has 1 to 2 CPUs

Policy Design: Number of Directory Searches

Authorization requires directory searches

Authorization doesn’t 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

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.

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.

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 properly sized user authorization cache will save 13333 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 Customer Secondary cs1, cs2

cp1, cs1, cp2, cs2

Employee Primary ep1, ep2 Employee Secondary es1, es2

ep1, es1, ep2, es2

Partner Primary pp1, pp2 Partner Secondary ps1, ps2

pp1, ps1, pp2, 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)

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

0

50

100

150

200

250

300

350

400

Without Password Services With Password Services

Tran

sact

ions

Per

Sec

ond

Vendor 1Vendor 2

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.

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.

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

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.

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

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.

Documents

Performance Planning & Tunning