Application Tier Performance

Contents
casso128
Contents
2
Policy Servers evaluate polices in the application tier and user credentials and attributes in the data tier to protect resources. Consider the following guidelines to performance tune the application tier:
  • The amount of system resources required to authenticate users affects performance.
  • The amount of system resources required to authorize users affects performance.
  • The number of Policy Server requests to user directories during authentication and authorization affects performance.
Policy Design and Performance
CA Single Sign-On
policies define how users interact with resources. When you create policies in the Administrative UI, you link together (bind) objects that identify users, resources, and actions associated with the resources.
You can improve or degrade performance in the way you configure specific components or by choosing to enable optional features. A performance strategy includes:
  • Identifying the policy objects that can affect performance
  • Identifying the parameters and features that affect user authentication
  • Identifying the parameters and features that affect user authorization
The business rules and security requirements of your enterprise should ultimately dictate your policy design. The following guidelines are available to help you balance
CA Single Sign-On
performance, while meeting these requirements.
CA Single Sign-On
Policy Objects and Performance Roadmap
CA Single Sign-On
requires that you configure core policy objects in a specific order. The following diagram lists this order, where shaded items represents objects that affect performance during user authentication or authorization.
The Host Configuration Object (HCO) and Agent Configuration Object (ACO) affect the performance of your Web tier.
auth and az policy components
auth and az policy components
Applications
You can improve or degrade performance during authentication and authorization in the way you configure applications.
An application is a Policy Server object that defines a complete security policy for one or more related web services. Applications associate web service resources with user roles to specify entitlement policies that determine what web service users can access what web service application resources.
When you create an application, you bind it to one or more user directory connections against which the Policy Server attempts to authenticate users. Therefore, the number of directory connections, and order in which they are listed, directly affects
CA Single Sign-On
performance during authentication.
The number of web service ports and operations that are defined as protected resources in an application correlates to
CA Single Sign-On
performance during authorization.
Resources can be bound to one or more responses. When a resource is accessed, the associated response returns information to an agent, such as user attributes, DN attributes, static text, or customized active responses.
The types of responses you bind to web service resources directly correlate to
CA Single Sign-On
performance during authorization.
Domains
You can improve or degrade performance during authentication in the way you configure domains.
A
CA Single Sign-On
policy domain is a logical grouping of resources associated with one or more user directories. When you create a domain, you bind one or more user directory connections to the domain.
The Policy Server attempts to authenticate users using these directory connections. Therefore, the number of directory connections, and order in which they are listed, directly correlates to
CA Single Sign-On
performance during authentication.
Realms
You can improve or degrade performance during authentication in the way you configure realms.
You group the resources in a domain into one or more realms. A realm is a set of resources (URLs) with a common security (authentication) requirement. The resource filter you define and the authentication scheme you select directly correlate to performance during authentication:
  • The resource filter functions as the root of the protected resources. The Policy Server must evaluate the resource filter to determine if the requested resource is protected (IsProtected?).
  • The authentication scheme associated with the realm determines the type of credentials users must present to gain access to the resources in the realm (IsAuthenticated?).
Realm settings also determine:
  • How
    CA Single Sign-On
    handles user sessions.
    CA Single Sign-On
    creates a user session in the context of the realm to which the user authenticated against.
  • If the realm can be used to control actions during authentication..
Rules and Rule Groups
You can improve or degrade performance during authorization in the way you configure realms.
You create rules or rule groups in the context of a realm. Rules:
  • Identify the specific resources within a realm that require protection
  • May be used to either allow or deny access to the resource based on specific authentication or authorization events.
The resource filter you define in the rule, which is prefixed with the realm filter, identifies the resource that requires protection.
The Policy Server evaluates rules to determine which resource filter best matches the requested resource. Upon a match, the Policy Server fires the policies to which the rule is bound to determine if the user is authorized to access the resource.
The number of rules within a realm and how you define each of the resource filters directly correlates to
CA Single Sign-On
performance during authorization.
Responses
You can improve or degrade performance during authorization in the way you configure responses.
Responses or response groups are bound to specific rule or rule groups. When a rule fires, a response can:
  • Customize the amount of time user sessions remain valid.
  • Redirect the user to other resources.
  • Customize the content the user receives based on attributes contained in a user directory.
  • Pass static text, user attributes, DN attributes, customized active responses, or the runtime values of defined variables from the Policy Server to an agent.
  • Instruct a WSS Agent to generate WS-Security headers and SAML Session Tickets
Policies rules can be bound to one or more responses. The types of responses you bind to policy rules directly correlates to
CA Single Sign-On
performance during authorization.
Authentication Guidelines
CA Single Sign-On
performance during the authentication (IsAuthenticated?) step typically correlates with:
  • The system resources used to service an authentication request
  • The number of reads/writes, collectively known as requests, that the Policy Server makes to user directories to service an authentication request
Policy Objects and Performance Roadmap
Authentication performance can improve or degrade depending on how you configure specific policy objects or by choosing to enable optional features associated with those objects.
CA Single Sign-On
requires that you configure core policy objects in a specific order. The following diagram lists this order, where shaded items represent objects that affect performance during user authentication.
policy objects and authentication performance
policy objects and authentication performance
User Directories and Authentication Performance
Configuring a domain requires that you bind one or more user directory connections to the domain. The Policy Server uses the search criteria you specify in the user directory connection to verify user credentials during the authentication step.
The following factors affect user authentication performance at the directory level:
  • Search expressions and queries—The more complex the LDAP expression or ODBC query, the longer it takes the Policy Server to resolve the criteria to authenticate the user.
  • Password Services—You can apply password policies to user directories. Consider the following before implementing password policies:
    • The Policy Server reads attributes related to the password policy and may need to update them. Updating an attribute requires the Policy Server to write to the user directory.
    • If the password policy is configured to track login details, an additional user directory write is required for every authentication.
    • The Policy Server takes longer to resolve password policies that only apply to a specific group of users within the directory, instead of the entire directory.
CA Single Sign-On
Web Services Security Authentication Schemes and Authentication Performance
Different Web Services Security authentication schemes impose different level of WSS Agent processing overhead, which can also vary between WSS Agent types.
In general, authentication throughput is greater for authentication schemes that do not require digital signature verification or payload confidentiality.
Digital signature verification is more CPU- and data-intensive on WSS Agent for Web Servers, but also slightly impacts WSS Agents for application servers.
Domains and Authentication Performance
The following factors affect user authentication performance at the domain (or application object general) level:
  • The number of directory connections in the domain—The Policy Server searches each user directory in the domain until it is able to validate the user credentials. The greater the number of user directory connections, the longer it can take the Policy Server to authenticate the user.
    Evaluate ways to reduce the number of directory connections in a domain to prevent unnecessary Policy Server requests. Consider:
    • Who is requesting the resources within the domain and in which directories their information is stored
    • Combining user directories when you add an organization to your
      CA Single Sign-On
      deployment
  • The order in which user directory connections are listed—The Policy Server searches user directories in the order in which the domain lists them. Evaluate authentication priorities when determining the order of connections. Consider:
    • If a larger percentage of users access the application from a specific directory or directories
    • If a smaller group of users exists that are higher priority for authentication
Realms and Authentication Performance
The following factors affect user authentication performance at the realm (or application object component) level. Consider each as you configure realms:
  • Credential collection—Realms are associated with a specific authentication scheme, some of which require the use of credential collectors. Agents protecting resources with these types of authentication schemes redirect users to the credential collector to gather the credentials. Gathering credentials adds an additional step to the authentication process.
  • Persistent Sessions—When
    CA Single Sign-On
    authenticates a user, the Policy Server issues a session ticket. A session ticket contains basic information about the user and the authentication context of the user. By default,
    CA Single Sign-On
    implements session management through non–persistent sessions, for which the Agent writes the session ticket to a cookie in the web browser of the user.
    Some
    CA Single Sign-On
    features require persistent sessions. You can configure a realm for Persistent Sessions. Agents protecting resources in this realm write the session ticket a
    CA Single Sign-On
    session store, which results in additional requests to the session store for each authentication.
    Persistent sessions can have a significant impact on performance.
  • Authentication Events—By default, a realm is configured to Process Authentication Events. This setting lets you define rules that fire when a user authenticates or fails to authenticate. Policy evaluation logic applies to all realms configured to process Authentication Events. This logic consumes system resources and can result in user directory requests.
    Evaluate the need for event actions that occur when users authenticate to gain access to a resource. If you do not require authentication actions, disable Authentication Events for the realm to speed the authentication step.
Authorization Guidelines
CA Single Sign-On
performance during the authorization step typically correlates with:
  • The system resources used to service an authorization request.
  • The number of reads/writes, collectively known as requests, the Policy Server makes to user directories to service an authorization request.
The complexity of your
CA Single Sign-On
policy design affects each of these areas.
Policy Objects and Performance
You can improve or degrade authentication performance in the way you configure specific policy objects or by choosing to enable optional features associated with those objects. The following policy objects can affect performance during user authorization:
Rules and Authorization Performance
The following factors affect user authorization performance at the rule (or application object resource) level:
  • Large numbers of rules in a single realm can slow authorization decisions. If a user is authenticated for a particular realm, the Policy Server must evaluate all rules within the realm to determine which of the resource filters best matches the specific resource (URL) the user is requesting.
  • The type of resource filter affects how quickly the Policy Server can evaluate the resource match.
The following filters are listed in the order in which they have the smallest affect on performance:
Exact match—Defining a resource filter with a specific resource has the smallest affect on performance. The Policy Server only has to compare the resource filter to the URL of the requested resource.
Example:
A company creates a customer realm (/customer) and specifies a rule with a specific page of their portal application (lending_home.html). The resulting resource filter is /customer/lending_home.html. Evaluating a match between the requested resource and the rule only requires the Policy Server to compare the requested resource with the resource filter to determine if it is a match.
  • Exact prefix—Defining a resource filter with a prefix has a greater affect on performance than an exact match. The Policy Server must determine if the requested resource is contained within the root (realm) of the resource.
    Example:
    A company creates an employee realm (/employee) and specifies a rule with "*.html". The * prefix specifies that all html files in the employee realm are protected. The resulting resource filter is /employee /*.html. Evaluating a match between the requested resource and the resource filter requires the Policy Server to evaluate if the requested resource is part of the employee directory and is an HTML file.
  • Regular expression—Defining a resource filter with a regular expression has the greatest affect on performance. The Policy Server must evaluate the expression and compare the result to the requested resource. The complexity of the expression further affects performance.
Responses and Authorization Performance
The type of response attributes bound to rules in a
CA Single Sign-On
policy affect performance. The following response types are listed in the order in which they have the smallest affect on performance:
  • Static—Defining a static attribute returns data that is constant.
  • User attribute—Defining a user attribute returns profile information from a user‘s entry in a user directory.
    This type of response requires the Policy Server to search the user directory.
  • DN attribute—Defining a DN attribute returns information associated with directory objects to which the user is related. Groups to which a user belongs, and organizational units (ou) that are part of a user DN, are examples of directory objects whose attributes can be treated as DN attributes.
    This type of response requires the Policy Server to search the user directory.
Policy Membership and Authorization Performance
Policy membership is the part of a
CA Single Sign-On
policy that specifies which users apply to the policy. Policies are stored in domains, and as a result, you use filters to apply policy membership to any or all users stored in the user directories bound to the domain. The type of filter you define determines how the Policy Server evaluates policy membership.
The following filters are listed in the order in which they have the smallest affect on performance:
  • All—"All" has the smallest affect on performance.
    When
    CA Single Sign-On
    authenticates a user, the Policy Server issues a session ticket. The session ticket identifies the user directory in which the user is stored. The Policy Server only has to compare the session ticket with the directory bound to the policy to determine that the policy applies to the user.
  • Distinguished name—A distinguished name (dn) has a greater affect on performance than "All".
    The organization or organizational unit, which contains the dn of the authenticated user, is stored in the session ticket. The Policy Server has to compare the session ticket information with the policy membership filter to determine if the policy applies to the user.
  • Group membership or search expressions—These types of filters have a greater affect on performance than distinguished names. Group membership and search expressions consume additional system resources and result in a user directory search. The Policy Server must:
    1. Resolve the group membership or search expression
    2. Search the user directory to determine if the policy applies to the user.
  • Nested groups—Defining policy membership with a nested group has the greatest affect on performance.
    The Policy Server must search each user group and all sub–groups in the directory to determine if the policy applies to the user.
    Directories with deep group hierarchies can have a significant effect on the time it takes the Policy Server to evaluate policy membership.
You can enable the User Authorization cache to reduce the number of requests the Policy Server makes to user directories to resolve policy membership.
User Authorization Cache
The user authorization cache reduces the number of user directory requests to determine policy membership by storing the relationship between users and policies.
The user authorization cache does not store data about the user, store user attribute values, or cache user entries.
For example, three policies are configured to apply to an "Administrator" group, to which user A belongs. The first–time the Policy Server evaluates policy membership, it must resolve the group membership and make three requests (one for each policy) to the user directory to determine that each policy applies.
The Policy Server writes these results to the user authorization cache. Subsequent policy evaluation does not require the Policy Server to make user directory requests. Rather, the Policy Server uses the cached authorization information to determine policy membership.
Note:
The Policy Server polls for policy updates periodically. The default interval is 60 seconds. If the policy membership changes, the Policy Server reloads the policy and removes the cache entries that are related to the updated policy.
User Authorization Cache Efficiency
The user authorization cache is most efficient when:
  • All user requests during a session are consistently sent (persisted) to the same server.
  • All agents are configured for Policy Server failover, not round–robin load balancing.
If these factors are not met, the efficiency of the User Authorization cache is reduced.
Example: the user authorization cache and agents configured to round–robin load balance
The more Policy Servers that are in the agent round–robin pool, the greater the chance that the efficiency of the user authorization cache is reduced.
If a single agent is configured to round–robin between two Policy Servers, the first request for a protected resource results in a user authorization cache entry on one of the Policy Servers. There is approximately a 50 percent chance that the Policy Server that does not have the cache entry must service the second request. Moving forward, however, both Policy Servers have cached the data for subsequent requests.
Consider now, the effect of a single Agent configured to round–robin between 10 Policy Servers. After a Policy Server authorizes a user and enters the result in to the authorization cache, there is only a 10 percent chance that the same Policy Server services the next request. In this configuration, 5 cache misses must occur before there is a 50 percent chance of a cache hit.
Policy Server clusters can reduce the effect round–robin load balancing has on the user authorization cache.
Estimate the Size of the User Authorization Cache
The default size of the user authorization cache is 10 MB. You can estimate the amount of space the user authorization cache requires and use the Policy Server Management Console to adjust the default size.
To estimate the size of the user authorization cache
  1. Use the following formula to estimate the number of cache entries:
    expected_users
    *
    number_of_policies_per_session = entries
    • expected_users
      Specifies the total number of users authenticating to the applications
      CA Single Sign-On
      is protecting.
    • number_of_policies_per_session
      Specifies the average number of policies that apply to a user during the session.
      Each policy has the potential to enter a unique entry into the user authorization cache.
    • entries
      Specifies the number of cache entries authorizations can create.
  2. Use the following formula to estimate the size of the cache:
    (
    entries
    * .000062) + 1
    .000062 represents the approximate size of a cache entry in MB.
Auditing and Performance
By default, the Policy Server writes audit events to a text file, which is known as the Policy Server log. Optionally, you can configure the Policy Server to log events to an audit database.
Consider the following factors if you decide to log events to an audit database:
  • Performance associated with authentication and authorization is affected because
    CA Single Sign-On
    is logging all authentication and authorization decisions to the database.
  • (Optional) Synchronous logging—You can configure synchronous logging at the realm level. If configured, the Policy Server prevents the result of each authentication and authorization request until the record is saved in the audit database. Users are not authenticated or authorized until the record is saved.
Load Balancing the Application Tier
Tuning the various agent parameters and following the
CA Single Sign-On
policy design guidelines may not significantly improve the amount of time it takes the Policy Server to service authentication and authorization requests.
When you have multiple Agents and Policy Servers, dynamic load balancing reduces latency and improves throughput because the Agents distribute requests among all of the Policy Servers.