Skip Headers
Oracle® Fusion Middleware Performance and Tuning Guide
11g Release 2 (11.1.2)

Part Number E28552-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

25 Oracle Access Management Performance Tuning

This chapter provides guidelines for tuning and sizing the services that make up an Oracle Access Management 11g Release 11.1.2 installation.

25.1 About Oracle Access Management

Oracle Access Management includes a full range of services that provide Web perimeter security functions and Web single sign-on; identity context, authentication and authorization; policy administration; testing; logging; auditing; and more.

Oracle Access Management is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides restricted access to confidential information and centralized authentication and authorization services. Many existing access technologies in the Oracle Identity Management stack converge in Oracle Access Management.

Starting with release 11.1.2, Oracle Access Management includes the following "services":

For more information on administering these services, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Note:

Prior to the Oracle Fusion Middleware 11.1.2 release some of the services discussed in this chapter, such as Oracle Identity Federation and Oracle Secure Token Service, were standalone products and tuned individually.

For information on tuning the 11.1.1 standalone versions of these services, see the Oracle Fusion Middleware Performance and Tuning Guide in the Oracle Fusion Middleware 11g Release 1 (11.1.1.6.0) documentation library.

25.2 Performance Considerations for Oracle Access Management Services

Identifying the areas of your Oracle Access Management environment that may impact performance is the first step in effective performance tuning. This section provides information on some of the common areas to review. Always consult your specific usecase scenarios and performance requirements to determine which configurations are applicable.

Before you begin tuning Oracle Access Management services, review the following sections as well as the recommendations discussed in Chapter 2, "Top Performance Areas":

25.2.1 Understanding Your Current Environment

Before tuning Access Management services consider the following:

Number of Users

Understanding the overall user population size; group, membership and attribute counts; data types, and configuration parameters of the LDAP and database is essential. See Performance Planning for more information on using population data to improve performance.

Daily Activity Usage

Access Manager: It is important to know how many users are active during a 24-hour period and the expected traffic. Spikes in usage may require additional tuning to avoid performance issues. See Monitoring Oracle Fusion Middleware for more information on collecting performance data.

Identity Federation: It is important to know how many Federated SSO requests are processed in a 24-hour period and the expected traffic. Spikes in usage may require additional tuning to avoid performance issues

Hardware Resources and Topology

Like any application deployed for interactive use in a demanding environment, proper server sizing and configuration is critical for acceptable performance. Ensuring that your hardware is sufficient to prevent bottlenecks is a key factor in performance tuning. See Securing Sufficient Hardware Resources for more information on optimizing hardware resources.

Partners and Protocols

When tuning Identity Federation, knowing which partners are configured, how those partners are modeled and the federation protocol used are important considerations. Specifically you should understand how many partners this instance has and what protection policies are assigned to them.

Protected Applications

Knowing which applications are being protecting and how that protection is modeled is an important consideration when tuning. Specifically you should understand how the applications are being protected: using Webgates (10g,11g, or 11gPS1); mod_osso; custom AccessGates; or a combination.

JVM and Garbage Collection

Optimal performance of the Access Management services depends on correctly tuning JVM heap sizes and garbage collection. See Configuring Garbage Collection and Specifying Heap Size Values in Tuning Java Virtual Machines (JVMs)for more information.

System Time Synchronization

Security tokens exchanged during protocol interactions are time sensitive. To avoid issues the system time across the topology needs to be synchronized. Identity Federation has the ability to mitigate this to a certain extent through support for clock skewing.

Message Profiles

WS-Trust is a very flexible protocol that allows you to request different token types using message exchange patterns that can vary widely. Knowing the message exchange patterns is a very important consideration for tuning Oracle Access Management Security Token Service.


25.2.2 Controlling Network Latency

The performance of the overall network is a major factor in the performance of the system. A reduction in network latency can improve network performance.

Access Manager provides keep alive, failover, and failback functionality to handle LDAP and network outages, replication, and related activities. The built-in features of Oracle Access Manager are often the same or better than similar features provided by a load balancer.

You may use Load Balancers to manage the Access Manager server communication information for OAP (Oracle Access Protocol) by virtualizing it. The benefits of using a Load Balancer between Webgates and Servers should be measured against the following constraining requirements:

  • OAP connections are persistent and need to be kept open for a configurable duration even while idle.

  • The Webgates need to be configured to recycle their connections proactively prior to the Load Balancer terminating the connections, unless the Load Balancer is capable of sending TCP resets to both the Webgate and the server ensuring clean connection cleanup.

  • The Load Balancer should distribute the OAP connection uniformly across the active Access Manager Servers for each WG (distributing the OAP connections according the source IP), otherwise a load imbalance may occur.

Caution:

If the above constraining requirements are not met, you can negatively impact the performance of Access Manager resulting in outages.

To control network latency, consider the following:

  • Add an SSL accelerator or load balancer outside of the Oracle Access Manager system to improve the performance of your network.

  • Deploying a load balancer in front of the Web servers or application servers is a best practice for increasing availability and performance of Web-based applications, including Oracle Access Manager. However, load balancers are not recommended between the Oracle Access Manager components themselves.

  • Place the Access Manager Servers closer to client applications than to the directory.

    During normal operations there can be a considerable amount of traffic between Webgates and Access Manager Servers. Locating these managed servers closer to the applications can reduce the latency between devices in high-traffic parts of the network.

25.2.3 Enabling DMS Performance Instrumentation

For performance tuning purposes, consider enabling Dynamic Monitoring Service (DMS) performance instrumentation which can tell you the latency and throughput of functional and operational metrics. DMS can identify components that are either processing a heavier load or taking longer than usual to service requests. See Viewing DMS Metrics for more information on determining the overall time to process calls to various components.

25.3 Tuning Oracle Access Management Access Manager

Oracle Access Management Access Manager (Access Manager) is an enterprise level solution that centralizes critical access control services to provide an integrated solution that delivers authentication, authorization, Web single sign-on, policy administration and enforcement, agent management, session control, systems monitoring, reporting, logging, and auditing.

For more information on using Access Manager, see "Introduction to Oracle Access Management Access Manager" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.3.1 Basic Tuning Considerations for Access Manager

Depending on your Access Manager usage and performance issues, you may consider tuning the following basic parameters. See Top Performance Areas for additional tuning considerations.

25.3.1.1 Tuning the Web Tier

Tuning your Web application's server is essential to maintaining optimal performance for Access Manager. This section describes tuning configurations for the following:

25.3.1.1.1 Tuning the Oracle HTTP Server

Access Manager Webgate is typically installed on the Oracle HTTP Server. To maximize Access Manager performance, review your use case scenarios to determine the best way to tune the HTTP Server.

At a minimum, consider tuning the following Oracle HTTP Server parameters shown in Table 25-1 in the httpd.conf file:

Table 25-1 Oracle HTTP Server Tuning Parameters and Descriptions for Webgate

Parameter Description

MaxKeepAliveRequests

A value of zero in the MaxKeepAliveRequests directive means there is no limit on the number of connections, which are kept alive expecting subsequent client requests.

Timeout

The total amount of time it takes to receive a GET request.

KeepAliveTimeout

The number of seconds HTTP Server will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies. See above.

Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.

If <IfModule mpm_worker_module> has been configured, then consider tuning the following:

StartServer

 

ServerLimit

 

MaxClients

 

ThreadsPerChild

 

MaxRequestsPerChild

 

AcceptMutex

 

LockFile

Consider modifying the OHS LockFile directive to a location on the local disk and not to a shared drive. This will help in avoiding known locking issues on the Oracle HTTP Server Reserve proxy as well as the Oracle HTTP Server Webgate server.


For more information on modifying the httpd.conf file, see "Configuring Oracle HTTP Server" in the Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.

25.3.1.1.2 Tuning Access Manager Webgate

Webgate is an out-of-the-box access client for Access Manager.This Web Server access client intercepts HTTP requests for Web resources and forwards them to the Access Manager Server. Webgates for various Web Servers are shipped with Access Manager. To maximize performance, consider tuning the Webgate connections to the Access Manager server.

Consider tuning the following parameters to increase the number of connections from the Webgate Server to the Access Manager servers. Adding more connections enables the servers to process more concurrent requests.

Parameter Description

Max Connections

Maximum number of connections that this Access Manager Agent can establish with all the Access Manager Servers.

Maximum Number Of Connections

Maximum number of connections that the Access ManagerAgent can establish with a specified Access Manager Server.


For more information on setting these parameters, see "Registering Agents and Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.3.1.2 Managing Policy Components

In order to limit the Access Manager processing overhead, all resources that do not require security should be modeled as excluded resources as opposed to unprotected resources. Modeling these resources as excluded resources can substantially help with ADF Applications. Excluded resources use a one-time interaction between the Webgate and the Access Manager Server as opposed to a per request interaction for unprotected resources.

For more information, see "Managing Shared Policy Components" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.3.1.3 Tuning the Data Tier Connections

LDAP stores are accessed by connection pools maintained by Access Manager. Identity store definitions contain the exposed pool parameters. Middleware Control and the DMS Spy Servlet can expose per-operation counts and latency which can be used to identify bottlenecks. Consider specifying an explicit time-out value (default=unlimited) and ensure that the initial and maximum number of connections in the pool are appropriate for the deployment.

For more information, see "Managing User Identity Stores" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.3.2 Advanced Tuning Considerations Access Manager

The following Access Manager tuning considerations are provided as a guide. Always consult your own use case scenarios to determine if these configurations should be used in your deployment.

25.3.2.1 Tuning Oracle Coherence

Oracle Access Manager uses Oracle Coherence to replicate session states within a distributed installation. Coherence is used to communicate state changes between the Oracle Access Manager Console and Access Manager Servers.

Oracle Coherence recommends that you configure your operating system (OS) to allow for larger buffers. Consider increasing the buffer to at least 2 MB.

For more information, see "Performance Tuning" in the Oracle Coherence Administrator's Guide.

25.3.2.2 Setting the Java Message Bean Pool Size

By default, the Access Manager Proxy is set to handle 100 concurrent Webgate requests. If necessary, consider adjusting the pool settings to reflect the maximum Webgate request load for the deployment. This is achieved by setting the max-beans-in-free-pool element to an appropriate value. This deployment configuration is available in the Weblogic Server Administration Console. For more information, see Configuring Connection Pools.

To choose the appropriate value for the max-beans-in-free-pool, calculate it based on the Web Tier settings discussed in Tuning the Web Tier. This value should be greater than the Max Number of connections (in Webgate) multiplied by the ServerLimit (in Oracle HTTP Server) multiplied by the Number of Webgates.

25.3.2.3 Tuning the Server Cache

The following server caches can be tuned to improve Access Manager performance:

25.3.2.3.1 Tuning Identity Store Cache

Authorization policy administration allows authoring of grants to users or groups. Administrators can search within specific identity stores, selecting certain users or groups and granting or denying them access. Search results provide canonical identifiers for users and groups such that those values are stored as principals of the Identity Constraint component of Access Manager Authorization policy. The console displays the names and the Identity Store of origin.

To maximize performance, review configuration settings of the following Identity Store caches:

  • Group Membership Cache

    The Group Membership cache stores indirect membership data which is essentially a group's membership in another group. The number of entries and entry time-to-live are configurable parameters. The cache should be tuned if your deployment includes groups that will be checked against or exported as responses, such as groups that are set in identity constraints, for example.

    CAUTION: The Group Membership Cache is populated by a recursive search of the entire LDAP tree of nested groups without any loop detection. Consider disabling this cache if you are experiencing degraded Access Manager Server performance.

  • User Attribute Cache

    User Attributes, once fetched, are always cached. Pre-fetching of attributes during authentication is controlled by specifying the attribute list in the SUPPLEMENTAL_RETURN_ATTRIBUTES parameter value of the Identity Store.

    Supplemental attribute return values are useful when you do not require the user to make a list selection for the attributes, yet you want those attributes values, as determined by the current row, to participate in the update.

25.3.2.4 Tuning Webgate Caches

Webgate caches information on authentication and on whether or not a resource is protected. Webgate cache tuning sets the total number of unique URLs expected over the timeout interval. Default is 0 URLs, but this means that the cache is not automatically updated and is flushed only when the administrator manually updates the cache. While this is a good option for performance in some scenarios, it may not apply to your individual use cases.

This section provides the following topics:

For more information, see "Reviewing OAM Agent Metrics" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.3.2.4.1 Introducing Webgate Caches

Webgate caches various information related to resources, authentications and authorizations to improve performance. It uses the cached information to avoid trips to 11g Server for requesting same information. Table 25-2 are the caches used by Webgate to maintain this information.

Table 25-2 Webgate Cache Types

Cache Type Description

Resource to Authentication Scheme

This cache maintains information related to authentication schemes being used.

Default: 100000 elements

See Also: "Tuning Maximum Cache Elements" and "Tuning Cache Timeout Values".

Authentication Scheme

This cache maintains information related to authentication schemes being used.

Default: 25 elements

Typically Authentication Scheme cache elements require less than 2 Kb of memory per element.

See Also: "Tuning Cache Timeout Values".

Resource to Authorization Policy

11g Webgate only

This cache maintains information related to resources accessed and associated authorization policy.

Default: 100000 elements

See Also: "Tuning Maximum Cache Elements" and "Tuning Cache Timeout Values".

Authorization Result

11g Webgate only

This cache maintains information related to authorizations associated with user sessions.

Default: 1000 elements

See Also: "Tuning Authorization Result Cache" and "Tuning Authorization Result Cache Timeout".


About the 11g Webgate Diagnostics Page

This page displays useful information related to currently effective Cache configuration parameters. It also displays runtime information about the caches that include information on the number of cached elements, number of hits and misses so far, and current memory usage of individual caches. The page is found at the following URL:

http://webserver:port/ohs/modules/webgate.cgi?progid=1

Note:

Changes to Webgate parameters are not reflected on Webgate until the next configuration refresh. For 11g Agents, the default configuration refresh interval is 10 minutes.

Tuning Maximum Cache Elements

By default, the Resource to Authentication Scheme and Resource to Authorization Policy caches are created to store 100000 elements. Typically, elements of these caches require less than 1 Kb of memory per element. Therefore, with 100000 elements in each of these caches, typical memory requirement for the caches will be 100000 Kb or 100 Mb each.

Considering memory requirements and your deployment, the Web Server being used and number of unique URLs in your application, you might want to increase or decrease the maximum number of elements to be cached.

Note:

Increase or decrease the Maximum Cache Elements parameter value as needed. If this is set to a value of -1, all Webgate caches are disabled.

For both 10g and 11g Webgates, you can tune the maximum number of elements to be cached property, by changing the Maximum Cache Elements parameter. Updates to this parameter require a Webgate restart.

To tune the maximum number of elements to be cached

  1. Locate and open the desired 10g or 11g Webgate registration page in the Oracle Access Management Console.

  2. Set the Maximum Cache Elements parameter as desired.

  3. Restart Webgate Web server.

Tuning Authorization Result Cache

By default, the Authorization Result cache is created to store 1000 elements. Authorization Result cache elements store the user session identifier, authorization policy identifier, and associated authorization result including any processed policy responses. Therefore, Authorization Result cache elements are bulky and generally require more than 2Kb of memory per element.

Considering memory requirements and the number of concurrent user sessions in your deployment, you might want to increase the number of elements to be cached.

To tune the number of elements to be cached

  1. Locate and open the desired 11g Webgate registration page in the Oracle Access Management Console.

  2. In User Defined Parameters, add or update maxAuthorizationResultCacheElems as desired.

  3. Restart Webgate Web server.

Tuning Cache Timeout Values

By default, the following caches are created with a timeout value of 1800 seconds or 30 minutes:

  • Resource to Authentication Scheme

  • Authentication Scheme

  • Resource to Authorization Policy

Elements in these caches are stored with an expiry time that forces these caches to be flushed on expiry.

Considering the frequency of updates to Authentication Schemes, and Authentication and Authorization Policies in your deployment, you might want to increase or decrease the default timeout value.

To tune the cache timeout

  1. Locate and open the desired 10g or 11g Webgate registration page in the Oracle Access Management Console.

  2. Set the Cache Timeout parameter as desired.

  3. Restart Webgate Web server.

Tuning Authorization Result Cache Timeout

By default, the Authorization Result Cache timeout value is set at 15 seconds. Elements in the Authorization Result Cache is stored with an expiry time that forces it to be flushed on expiry. A low timeout value ensures that authorization results are cached for a small amount of time only.

Considering average length of user sessions and frequency with which user sessions are created and destroyed, you might want to change the default timeout value. Unlike other caches and parameters, updates to this parameter do not require Webgate restart. Instead, the updated value is dynamically picked up by 11g Webgate and enforced immediately.

Note:

If authorizationResultCacheTimeout is set to 0, Authorization Cache is disabled.

To tune the authorization result cache timeout

  1. Locate and open the desired 11g Webgate registration page in the Oracle Access Management Console.

  2. In User Defined Parameters, add or update authorizationResultCacheTimeout as desired.

  3. Restart Webgate Web server.

25.3.2.4.2 Reducing Network Traffic Between Components

The Webgate-to-OAM Server configuration polling reduces the traffic between both the Webgate and OAM Server and the OAM Server and the registered data stores for Oracle Access Manager.

Process overview: Webgate-to-OAM Server configuration polling

  1. When the Webgate is inactive for 60 seconds, it reduces the frequency of polling for its configuration information.

    The polling frequency is determined by the parameter InactiveReconfigPeriod, which is a user-defined parameter that is set in the Webgate configuration page. The value for InactiveReconfigPeriod is specified in minutes. Within ten seconds of resuming activity, the Webgate performs reconfiguration polling once a minute.

  2. At startup, the Webgate checks the bootstrap configuration to see if any important parameters have changed.

    This makes the re-initialization process unnecessary in most cases and reduces the transient OAM Server load.

  3. Webgate configurations are cached in the OAM Server.

    The default cache timeout is 59 seconds. This should cause no modifications to the system behavior on non-Apache access clients. The Apache Web server with Webgate avoids unnecessary hits to the directory server. The caching parameters can be set in the Webgate registration page.

    • Max Cache Elements sets the maximum size of the cache (default 9999)

    • Cache Timeout determines the maximum lifetime of any element in the cache (default 59 seconds)

There are two ways to reduce off-time network traffic between both the Webgate and OAM Server and the OAM Server and the database:

  • Changing the default configuration cache timeout for Webgate configurations that are cached in the OAM Server, as described in Step 3.

  • Changing Webgate polling frequency for configuration information, as described next.

25.3.2.4.3 Changing the Webgate Polling Frequency

One way to reduce off-time network traffic between both the Webgate and OAM Server and between the OAM Server and the database is to change the Webgate polling frequency using the InactiveReconfigPeriod parameter.

The default is 1 minute. When the Webgate is inactive for more than 60 seconds (for example, when no authentication requests are being processed), it reduces the frequency of polling for its configuration information. Within ten seconds of resuming activity, the Webgate resumes reconfiguration polling once every minute:

  • If set to -2, Webgate never polls.

  • If set to a value greater than 0 it polls at the specified interval.

  • If set to -1 and Webgate is inactive and has been for 1 minute, then Webgate does not poll. Webgate resumes reconfiguration polling when it returns to an active state.

For example, the OAM Server reads the shared secret from the directory at an interval of 10 minutes and this cached value is returned to Webgate. In the idle state the Webgate reads the shared secret from the OAM Server using the InactiveReconfigPeriod value. If this value is not set, the Webgate polls the OAM Server for the shared secret value at an interval of 1 minute even though the updated shared secret value will be returned only after 10 minutes.

To change the configuration polling frequency

  1. Locate the desired Webgate registration page using instructions in "Searching for a Webgate Registration" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  2. Add the InactiveReconfigPeriod parameter as a user-defined parameter on the Webgate registration page.

  3. Specify the value for InactiveReconfigPeriod in minutes.

  4. Apply your changes to the Webgate registration page.

25.3.2.5 Changing Request Cache Type

The default Request Cache type is set to COOKIE, which relies on the use of cookies to cache an unauthenticated request state.

Changing the type to BASIC can improve performance, but it is important to consider the following: If the server being used for an authentication flow goes down in the middle of that flow, the user's current state in the flow will be lost on their next request as the load balancer sends them to a different server.

Changing the type to FORM can improve performance when lengthy URLs are being accessed.

25.3.2.6 Tuning Authentication Plug-Ins

Authentication plug-ins can affect performance. When you develop customizations for Access Manager, consider the following to minimize performance impact:

  • Evaluate the sequence in which actions are executed

  • Minimize the plug-in footprint and external dependencies whenever possible

25.3.3 Specific Use Cases That Require Additional Tuning for Access Manager

This section describes some specific use cases that require specialized tuning, in addition to the Basic Tuning Considerations for Access Manager.

25.3.3.1 Managing Access Manager Sessions

By default, there can only be a maximum of 8 concurrent sessions for a given user ID. It is possible to raise this limit, but it is important to note that as the limit increases the security value of the feature is eroded, and ultimately disappears. Further, there is a performance cost associated with the feature, which increases with the limit. Therefore, if there is a need to have more than 20 concurrent user sessions, then consider disabling this feature by setting the limit to 0.

For more information, see "Administering Access Manager Sessions" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.4 Tuning Oracle Access Management Identity Federation

Oracle Access Management Identity Federation (Identity Federation) 11gR2 is an identity federation server built into the Oracle Access Manager server. All configuration is performed in Oracle Access Manager; unlike the standalone 11gR1 version. Identity Federation provides a self-contained and flexible multi-protocol federation server that can be rapidly deployed with existing identity and access management systems. It enables you to securely share identities across vendors, customers, and business partners without the increased costs of managing, maintaining, and administering additional identities and credentials.

For more information on administering Oracle Access Management Identity Federation, see "Introduction to Identity Federation in Oracle Access Management" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.4.1 Basic Tuning Considerations for Identity Federation

The following sections describe basic tuning configurations that you should also consider while tuning Identity Federation:

25.4.1.1 Tuning the Load Balancer and HTTP Server

As of Oracle Fusion Middleware Release 11gR2, some of the features of Identity Federation are embedded in Access Manager. To optimize Identity Federation performance, follow the Load Balancer and HTTP Server tuning guidelines discussed in Tuning the Web Tier for Access Manager.

25.4.1.2 Tuning SOAP Connections

Identity Federation uses the Simple Object Access Protocol (SOAP) to send Security Assertion Markup Language (SAML) requests and to receive SAML responses. To optimize performance, configure the following SOAP connections:

  • Total maximum number of SOAP connections that Identity Federation and Security Token Service can open at the same time

  • Maximum number of SOAP connections that Identity Federation and Security Token Service can open at the same time to a given remote server

25.4.1.3 Tuning the Data Tier Connections

LDAP stores are accessed by connection pools. Identity store definitions contain the exposed pool parameters. As discussed in Section 25.3.1.3, Middleware Control and the DMS Spy Servlet can expose per-operation counts and latency. Identity Federation uses an RDBMS to store session and runtime data. The server uses a caching mechanism to improve performance at run time. This enables the server to keep a reference to recently used objects in memory to avoid read access to the database. In addition there is an asynchronous write and delete mechanism to the RDBMS.

Note:

The following parameters typically do not need to be changed. Review the descriptions, however, to determine if an adjustment could improve performance for your deployment.

To optimize RDBMS session caching and asynchronous writes, configure the parameters as described in Table 25-3:

Table 25-3 Asynchronous Write Settings

Parameter Description

rdbmsasynchronousmanagerinterval

Execution interval for the asynchronous thread manager

rdbmsasynchronousmanagersleep

Sleep interval for the asynchronous thread manager, to check if execution should occur

rdbmsasynchronousqueuesize

Size of the queue containing RDBMS operations of the same type (create session, create artifact…)

NOTE: It is important to size the rdbmsasynchronousqueuesize correctly. If it is made too large, it can cause a lag in the asynchronous write to the database and may cause SSO operation to fail.

rdbmsasynchronousqueuesleep

Sleep time before the calling thread can retry to add an operation to a queue, in case the queue is full

rdbmsasynchronousqueueretries

Number of retries when trying to add an operation to the queue

rdbmsasynchronousthreadcore

Number of default threads in the RDBMS thread executor module for RDBMS asynchronous operations

rdbmsasynchronousthreadkeepalive

Maximum amount of time to keep the extra threads in the RDBMS thread executor module for RDBMS asynchronous operation

rdbmsasynchronousthreadmax

Maximum number of threads in the RDBMS thread executor module for RDBMS asynchronous operation

rdbmsasynchronousthreadmax should be adjusted to handle the maximum system load based on the size of your system.

rdbmsasynchronousthreadpolicy

Thread policy of the RDBMS thread executor module for RDBMS asynchronous operation

rdbmsasynchronousthreadqueuesize

Size of the thread queue of the RDBMS thread executor module for RDBMS asynchronous operation


Table 25-4 describes the RDBMS memory cache settings for artifact and transient cache:

Table 25-4 Cache Settings

Parameter Description

RDBMS Artifact memory cache settings, used in conjunction of the RDBMS asynchronous module:

artifactrdbmscachetimeout

Time to live in the memory cache

artifactrdbmsretries

Maximum number of time to retry to locate an entry in RDBMS before returning a failure

artifactrdbmssleep

Sleeping time between retrying lookup operations

RDBMS Memory cache settings (except for Artifact):

transientrdbmscachesize

Size of the cache

transientrdbmscachetimeout

Time to live for the objects in the cache, before being invalid and thus forcing an RDBMS lookup operation when an object is searched

Interval for the RDBMS cleanup thread

Indicates the interval of sleep of the thread removes expired entries from OIF DB tables


25.4.2 Advanced Tuning Considerations for Identity Federation

This section provides advanced tuning recommendations which may or may not apply to your environment. Review the following recommendations to determine if the changes would improve your Identity Federation deployment.

25.4.2.1 Tuning Oracle Coherence

Identity Federation, as part of Access Manager 11gR2, uses Oracle Coherence to replicate session states within a distributed installation. See Tuning Oracle Coherence for more information.

25.4.2.2 Tuning Identity Store

Identity Federation, as part of Access Manager 11.1.2.0.0, will benefit from tuning the identity store as discussed in Tuning the Server Cache.

25.4.2.3 Tuning Protocol Binding

This section describes the protocol binding options:

  • XML Digital Signatures

    Identity Federation relies on XML Digital Signatures to ensure the authenticity of messages and that messages are not tampered with.

    When possible, sign the Assertion and/or the Response to prevent any modifications. When no XML Digital Signature is present on the message, the audited message that is archived does not contain any data that proves the authenticity and integrity of the message.

    Configuring Identity Federation or Security Token Service to not sign Assertion and/or Response may be appropriate if:

    • Performance must be improved

    • SSL with SSL authentication is enabled for SOAP communications

    • Disabling XML Digital Signatures is compliant with company security regulations

  • XML Encryption

Federated Single Sign-On allows the use of token and element level encryption to provide confidentiality to the message exchange. Disabling use of encryption improves the latency and throughput of Identity Federation.

25.4.2.4 Tuning the Browser POST and Artifact Single Sign-On Profiles

There are two Single Sign-On profiles defined by the SAML specifications:

  • POST Profile

    In the POST profile, the Assertion transits through the user's browser, therefore the Assertion and/or the Response must be signed to ensure that the content has not been modified.

  • Artifact Profile

    In the Artifact profile, the Identity Provider creates a random identifier referencing the Assertion in the IdP's local store. (The Assertion is provided directly from the Identity Provider to the Service Provider.) That identifier is carried by the user's browser and presented to the Service Provider that contacts the Identity Provider to de-reference the identifier and retrieve the corresponding Assertion.

    If the SOAP connection made from the SP to the IdP is encrypted using the SSL protocol with an SSL Server Certificate, then the SP authenticates the IdP and the content of the communication has not been tampered with: in this case, the transport layer is providing the authenticity and the integrity of the message, and the XML Digital Signature on the SAML Response and Assertion can be optional.

    If no XML Digital Signature is present on the message, then the audited message that is archived does not contain any data that proves the authenticity and integrity of the message.

    Since the Artifact profile involves an additional round trip between the Service Provider and the Identity Provider, you may be able to improve performance by avoiding use of the Artifact profile.

25.4.3 Specific Use Cases That Require Additional Tuning for Identity Federation

This section describes some specific use cases that may benefit from additional tuning.

25.4.3.1 Message Signing versus Token Signing

Message exchange between the Service and Identity providers may be signed. Message signature provide additional security when the request/response transits numerous intermediaries. Disabling message signatures can improve performance but this should be done only when the security risk of doing so is mitigated by other security mechanisms

25.5 Tuning Oracle Access Management Security Token Service

Oracle Access Management Security Token Service (Security Token Service) provides a centralized mechanism to broker trust between applications and web services by enabling seamless propagation of identities and security context.

For more information on administering Security Token Service, see "Introduction to Oracle Access Management Secure Token Service" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

25.5.1 Basic Tuning Considerations for Security Token Service

The following sections describe basic tuning configurations that you should also consider while tuning Security Token Service:

25.5.1.1 Tuning the Load Balancer and HTTP Server

To optimize Security Token Service performance, follow the Load Balancer and HTTP Server tuning guidelines discussed in Tuning the Web Tier for Access Manager.

25.5.1.2 Tuning SOAP Connections

Security Token Service uses the Simple Object Access Protocol (SOAP) to send Security Assertion Markup Language (SAML) requests and to receive SAML responses. To optimize performance, configure the following SOAP connections:

  • Total maximum number of SOAP connections that can open at the same time

  • Maximum number of SOAP connections that can open at the same time to a given remote server

25.5.1.3 Tuning the Data Tier Connections

Security Token Service uses an RDBMS to store runtime data. The server uses a caching mechanism to improve performance at run time. This enables the server to keep a reference to recently used objects in memory to avoid read access to the database. In addition there is an asynchronous write and delete mechanism to the RDBMS. See Section 25.4.1.3, and review the tuning parameters discussed in Table 25-3 and Table 25-4 as these parameters should also be set for Security Token Service.

In addition, because the LDAP connections are made from Security Token Service when LDAP credential validation is enabled in a validation template in Security Token Service, the connections to that LDAP instance should be tuned with the following parameters:

  • Setting the LDAP Inactivity setting which tells Security Token Service how long an LDAP connection should be kept in a pool before being removed due to inactivity.

    Over time, the LDAP server may close some connections due to a long inactivity period, and if left unchecked, this can result in errors and may impact performance.

  • Setting the LDAP Read Timeout Setting. Sometimes the LDAP server can become unresponsive, causing the thread/user to wait for a response or an error.

    To avoid waiting too long for an error when the server is not responding, Security Token Service sets a read timeout property on the LDAP connection. If the LDAP server does not respond before the read timeout period, an error is generated. Security Token Service closes the connection, open a new one and re-issue the LDAP command.

  • Setting the High Availability (HA) LDAP Flag.

    When integrated with LDAP Servers that are deployed in HA mode, STS must configured to indicate that the LDAP Servers are in HA mode.

25.5.2 Advanced Tuning Considerations for Security Token Service

This section provides advanced tuning recommendations which may or may not apply to your environment. Review the following recommendations to determine if the changes would improve your Security Token Service deployment.

25.5.2.1 Tuning the WS-Security Policy

To optimize Security Token Service performance, consider following the recommendations below when configuring your WS-Security Policy:

  • Optimal use of Integrity, Confidentiality and RequiredElements assertion

  • Optimal use of security binding properties

  • Use TransportBinding over SymmetricBinding, which in turn should be considered before AsymmetricBinding

  • Avoid encrypting the token for the WS Provider

25.6 Tuning Oracle Access Management Mobile and Social

Oracle Access Management Mobile and Social (Mobile and Social) is a new intermediary between a user seeking access to protected resources, and the back-end Identity and Access Management services that protect the resources. Mobile and Social provides simplified client libraries that allow developers to quickly add feature-rich authentication, authorization, and identity capabilities to registered applications. On the back-end, the Mobile and Social pluggable architecture lets system administrators add, modify, and remove Identity and Access Management services without having to update user installed software

25.6.1 Basic Tuning Considerations for Mobile and Social

The following sections describe basic tuning configurations that you should also consider while tuning Mobile and Social:

25.6.1.1 Tuning the Access Management Authentication Service Provider

Mobile and Social has an out-of-the-box Oracle Access Management Authentication Service Provider which connects to Oracle Access Management server using Access Manager SDK components. To optimize Mobile and Social, consider tuning Access Manager as described in Section 25.3, "Tuning Oracle Access Management Access Manager".

In addition to tuning the Access Manager configuration parameters, there is one configuration parameter that should be tuned in Mobile and Social:

Table 25-5 Mobile and Social Tuning Parameters

Parameter Description

OAM_SERVER_x_MAX_CONN

Use the following steps to configure the maximum number of connections provided for the Access Management server:

  1. From the Access Manager 11g R2 console, click System Configuration tab and select Mobile and Social on the left panel

  2. Under "Authentication Service Provider", select the target Access Manager service provider

  3. Change the value for OAM_SERVER_x_MAX_CONN properly for your performance requirements.

  4. Save the change.

NOTE: This parameter should be set to be the same value as defined for the "Max Connection for webgate agent" in Access Manager. If different values are provided then the setting in Access Manager server will take precedence.


25.6.1.2 Tuning the User Profile Service Provider

The User Profile Service in Mobile and Social depends on IDS/libOVD to connect to the user repository. There are two IDS/libOVD configuration parameters that can be tuned for the production deployment as described below. These parameters can be changed via Mobile and Social Administration Console.

Table 25-6 User Profile Service Provider Tuning Parameters

Parameter Description

Connection Pool Initial Size

Category: LDAP Adapter Properties

Default: 5

Recommendation: The default value an be used.

Connection Pool Maximum Size

Category: LDAP Adapter Properties

Default: 10

Recommendation: Tune the size of the LDAP connection pool in Oracle Virtual Directory LDAP Adapter to be at least as high as the total number of Threads configured in the Oracle Virtual Directory Listeners that actively use the LDAP Adapter.


For more information about libOVD configuration parameters, see Chapter 24, "Oracle Virtual Directory Performance Tuning".