1. Tuning Performance Guide
  2. Oracle Identity and Access Management
  3. Oracle Access Management Performance Tuning

12 Oracle Access Management Performance Tuning

This chapter provides guidelines for tuning and sizing the services that make up an Oracle Access Management 12c Release 12.2.1.4.0 installation.

Parent topic: Oracle Identity and Access Management

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":

  • Oracle Access Management Access Manager (formerly the standalone product named Oracle Access Manager)

  • Oracle Access Management Security Token Service (formerly the standalone product named Oracle Secure Token Service)

  • Oracle Access Management Identity Federation (formerly the standalone product named Oracle Identity Federation)

  • Oracle Access Management Mobile and Social (formerly the standalone product named Oracle Identity Connect)

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.

Parent topic: Oracle Access Management Performance Tuning

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 Top Performance Areas:

Parent topic: Oracle Access Management Performance Tuning

Understanding Your Current Environment

Before tuning Access Management services consider the tuning recommendations described in Table 12-1:

Table 12-1 Understanding Your Current Environment: Tuning Considerations

Tuning Consideration Description

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

NOTE: When uploading large Plugins or CRLs (10MB+) through the OAM Console UI, you need to ensure that the OAM Server heap size is optimally tuned to overcome OutOfMemory issues.

For example, increase the -Xmx and XX:MaxPermSize if the following error message is seen in the OAM logs: 

javax.management.RuntimeErrorException: GC overhead limit exceeded

Use Parallel, Concurrent Mark and Sweep GC modes with the JVM running in the Server Mode. In addition, Oracle reccomends to set the Heap size to a large value and use the same values for Minimum and Maximum (-Xms=-Xmx) .

Parent topic: Performance Considerations for Oracle Access Management Services

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.

To control network latency, consider the following:

  • Keep database repositories close to the OAM servers. Installing OAM servers on a remote server may cause significant latency. Latency between the application tier and the database tier should be 5ms or less to maintain optimal performance.

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

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.

Note:

In addition to ensure fast failover, tune the settings for fast failover. The defaults rely on the OS TCP/IP settings which must be tuned for the OS on which the Webgate is running.

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.

Ensure that the LDAP timeout under load are negligible. This requires ensuring that LDAP Server is appropriately patched and load testing be performed to simulate OAM LDAP queries (bind, user/group lookup, search queries). LDAP timeouts under load increases OAM Server SSO latencies and increase the risk of an OAM server outage.

Temporary latency blips (for example, increase in LDAP query latency, server processing due to increased Coherence latency) results in increased Webgate response times. If the Web Tier does not have adequate capacity to handle the incoming user requests (through queuing or throttling) especially during peak load, you may run into a situation where the entire Web Tier is blocked and unable to accept new requests.This results in end users not being able to login to access business application.

Parent topic: Performance Considerations for Oracle Access Management Services

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.

Note:

If you are using Enterprise Manager Grid Control, create Dashboard Reports based on the OAM Metrics of most interest, which can then be email’d on a regular schedule.

Parent topic: Performance Considerations for Oracle Access Management Services

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.

Parent topic: Oracle Access Management Performance Tuning

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.

Parent topic: Tuning Oracle Access Management Access Manager

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:

Parent topic: Basic Tuning Considerations for Access Manager

Tuning Oracle HTTP Server

You can tune Oracle HTTP Server (OHS) to optimize its performance as the web server component for Oracle Fusion Middleware.

Note:

The configuration examples and recommended settings are for illustrative purposes only. Consult your own use case scenarios to determine the configuration options that can provide performance improvements.

Parent topic: Tuning the Web Tier

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.

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 Administering Oracle Access Management.

Parent topic: Tuning the Web Tier

Tuning OAM Agents

Once you have registered an OAM Agent, you can tune the following parameters to the recommended values:

Parameter Recommendation

Cache Pragma Header

Delete the default of no-cache so that this field is empty.

Cache Control Header:

Delete the default of no-cache so that this field is empty.

AAA Timeout Threshold

Default is -1, which means that there no timeout. You should change this to a hard number.

Too low a number means that the socket connection can be closed before a reply comes from the OIM server. Too high a number means the connection may hang while waiting for a response.

Max Number of Connections for Each Server

For each server under Server Lists, change the Max Number of Connections from 1 to 10

To find these parameters, navigate the following menus: OAM11g Admin console > SystemConfig (tab) > Access Manager Settings > ssoAgents > OAM agents > (search and select the agent).

For more information on these parameters, see "Understanding Registered OAM Agent Configuration Parameters in the Console" in Administering Oracle Access Management.

Parent topic: Tuning the Web Tier

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 Administering Oracle Access Management.

To design authentication policies for optimal performance, do the following:

  • Get an inventory of all attributes you want for authZ and pre-fetch them at AuthN time.

  • Combine attributes in the supplementary list to reduce AuthN time LDAP load.

Note the following:

  1. Change all OAM policy responses for userid return from $user.attr.uid to $user.userid.This is because the latter is computed at login time as opposed to the former which is computed onDemand during authorization

    OAM_REMOTE_USER is populated by default.

  2. To design authorization policies for optimal performance, do the following:

    • Use $session namespace. Attributes used for authorization must be retrieved and stored in the user's OAM session during login. This ensures that the authZ latency is constant to make OAM responsive thereby improving the user experience.

      For example, modify ismemberof, loa and any other attribute related policy response to get value at authentication time instead of authZ time. 

      [Authentication Policies]ismemberof -> SESSION -> $user.attr.ismemberof
loa -> SESSION -> $user.attr.loa
uid ->SESSION -> $user.userid

 [Authorization Policies]Responses:
uid: $user.userid
ismemberof: $session.attr.ismemberof
loa: $session.attr.cmsRoles

    • For Authorization policies involving attributes, store and use attributes in the $session namespace instead of query them on-the-fly by using the $user.attr namespace.

    • Use group based policies instead of explicitly listing users.

Tuning Common Settings

All OAM Servers and services in the domain share a set of common settings. You can tune them from the Launch Pad. See "Managing Common Settings" in the Administering Oracle Access Management for how to find these settings.

This section provides tuning values for the following Common Settings:

Global Session Settings

The recommended values for the following parameters:

Session Lifetime = 5m

Maximum Number of Sessions should be set somewhere between 0 and 8. The default for this setting is 8. Usually the default is sufficient, but this number should be as low as possible. Note that setting this parameter to 0 means that a user can have unlimited sessions running concurrently, which is inadvisable.

For descriptions of these parameters, see "About Global Session Lifecycle Settings" in the Administering Oracle Access Management.

Parent topic: Tuning Common Settings

Default and System Identity Stores

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.

See Tuning the Data Tier Connections for more advanced tuning recommendations.

For more information on the how to find these settings, see "Defining the User Identity Store Registration Settings" in the Administering Oracle Access Management for more information.

Parent topic: Tuning Common Settings

Advanced Tuning Considerations for 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.

Parent topic: Tuning Oracle Access Management Access Manager

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.

This section contains the following topic:

Updating Optimization Interval Time

In the oam-config.xml file, the value of the OptimizedSessionUpdatesIntervalInMillis element should be less than the value configured for Idle Timeout parameter, which is 15 minutes by default.

In the configuration file, the OptimizedSessionUpdatesIntervalInMillis element appears as follows: 


      <Setting Name="DBSMEConfig" Type="htf:map">    
      <Setting Name="SessionCreationLockAcquirePercentage" Type="xsd:integer">60</Setting>
      <Setting Name="SessionPurgeLockExpiryIntervalSeconds" Type="xsd:long">3000</Setting>  
      <Setting Name="SessionCreationLockExpiryIntervalSeconds" Type="xsd:long">10</Setting>
      <Setting Name="SessionConcurrencyHardLimit" Type="xsd:long">5</Setting>    
      <Setting Name="OptimizedSessionUpdatesIntervalInMillis" Type="xsd:long">180000</Setting>
      </Setting>

Note:

This configuration should be under the XPath /DeployedComponent/Server/NGAMServer/Profile/Sme.

Based on the configured interval, the session updates during authorization will be optimised and it should be within the limit mentioned above. It is recommended to configure a minimum interval value to avoid any unexpected behaviour. In most of the cases, default value of 3 minutes (180000 ms) is sufficient to handle the load.

Parent topic: Tuning Oracle Coherence

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.

You can also calculate the appropriate value for the max-beans-in-free-pool 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.

Tuning the Server Cache

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

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.

    Note:

    All LDAP Attribute Condition used in Authz Policy must be retrieved during login and be cached. This improves authz latency and throughout while reducing the burden on the LDAP tier.

Parent topic: Tuning the Server Cache

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.

For more information, see "Reviewing OAM Agent Metrics" in Administering Oracle Access Management.

This section provides the following topics:

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 12-2 are the caches used by Webgate to maintain this information.

<<<used for AccessClients too?>>>

Table 12-2 Webgate Cache Types

Cache Type Description

Resource to Authentication Scheme

This cache maintains information related to authentication schemes being used.

Default: 100000 elements

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

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

After upgrading Oracle Webgate 10.1.4.3.0 to Bundle Patch 13 (BP13), the output of the Diagnostic page is a blank page.Starting with Bundle Patch 13, the Diagnostic Page is disabled by default.

To enable this page, per Webgate registration, add the parameter/value : enableDiagnosticPage=true in the list of user parameter of the webgate.With a Webgate instance already registered:

  • Go to OAM Console > System Configuration > Access Manager > SSO Agents > OAM Agents : Search and Select your Webgate profile

  • Add in the end of the list of the "User Defined Parameters" : enableDiagnosticPage=true.

  • Click on Apply: a pop-up window mentions where the new artifacts are located.

  • Copy the newly ObAccessClient.xml in the OHS configuration instance.

  • Restart the OHS instance and check that the Diagnostic Page is displayed.

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.

How 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 Manager 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.

How to tune the number of elements to be cached

  1. Locate and open the desired 11g Webgate registration page in the Oracle Access Manager 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.

How to tune the cache timeout

  1. Locate and open the desired 10g or 11g Webgate registration page in the Oracle Access Manager 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.

How to tune the authorization result cache timeout

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

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

  3. Restart Webgate Web server.

Parent topic: Tuning Webgate Caches

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 and AccessClient 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 and AccessClient configurations that are cached in the OAM Server, as described in Step 3.

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

Parent topic: Tuning Webgate Caches

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

Parent topic: Tuning Webgate Caches

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.

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

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.

Parent topic: Tuning Oracle Access Management Access Manager

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.

Audit Settings

OAM tends to generate a lot of audit information. During peak business hours, OAM generates audit information at a rate that is faster than the rate at which the OPSS AuditLoader can move the information to the Audit Database.

Given that SSO is a security service, it is recommend to set the Audit Filter to a value of MEDIUM or ALL. Also, ensure that the Audit BusStop directory has no max size limit (maxDirSize=0) to avoid zero data losses. In addition, monitor and confirm that the Audit data is constantly being moved to the Audit Database even if the AuditLoader falls behind during peak business hours.

Managing Monitor Account

Enterprises use automated monitors to measure end user latency and generate alerts when thresholds are exceeded.

Oracle recommends the following best practices:

  1. Monitors should logout when their work is done. This ensures that sessions do not pile up in memory.

  2. Monitors should not use the same user credential. This ensures that a single user does not create a very large number of sessions in a short amount of time.

  3. Prune monitor sessions periodically. This can be done through the OAM Console or by writing a program using the ASDK. It also ensures that you do not have to set the maximum number of sessions to a very large value to accommodate monitors.

  4. Refrain from running monitors very frequently when problems are seen.

    Typically, monitors are set to run very frequently when an exception condition is noted (for example, when login latencies exceed the threshold). This has the effect of putting additional load on the system especially if this happens under peak load and this increases the risk of a catastrophic failure.

Kerberos Latency Issues

Kerberos authentication, by default, uses the UDP protocol. However, UDP does not perform well when the connection between the OAM Server and Kerberos Server has to span subnets or the packet loss increases during business hours. As a result, it recommended that Kerberos be configured to use TCP instead of UDP.

This can be done by setting udp_preference_limit=1 in the /etc/krb5.conf file.

Oracle Access Protocol over REST Connectivity Issues

Oracle Access Protocol (OAP) over REST enables the use of HTTP infrastructure to route and load balance requests. This is a new feature introduced in WebGate starting with release 12.2.1.4.0. Under load, you may see connection errors in the WebGate and/or HTTP Server logs.

Oracle recommends the following best practices to reduce the connection errors:
  • Ensure that the HTTP Server has enough idle or spare Server threads to receive incoming requests.
  • Increase the OAM WebLogic Server wm/OAPOverRestWM work manager capacity.
  • Optionally, increase the RAM allocated to the HTTP Server and the WebLogic Server.

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 Administering Oracle Access Management.

Parent topic: Oracle Access Management Performance Tuning

Basic Tuning Considerations for Identity Federation

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

Parent topic: Tuning Oracle Access Management Identity Federation

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.

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

Tuning the Data Tier Connections

LDAP stores are accessed by connection pools. Identity store definitions contain the exposed pool parameters. As discussed in Default and System Identity Stores, 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 runtime. This enables the server to keep a reference to recently used objects in memory to avoid read access to the database. The RDBMS also has an asynchronous write and delete mechanism.

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 12-3:

Table 12-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 12-4 describes the RDBMS memory cache settings for artifact and transient cache:

Table 12-4 Cache Settings

Parameter Description

RDBMS Artifact memory

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

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

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.

Parent topic: Tuning Oracle Access Management Identity Federation

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.

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.

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.

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.

Outbound SOAP Connections

OAM Federation can communicate with remote SAML Servers using different bindings, among them the SOAP binding. When OAM needs to send a message to a remote server using the SOAP protocol, it will directly open a connection and send a SOAP message.

You can configure the following connection settings:

soapmaxconnections - The maximum number of concurrent connections that OAM Federation can open when sending SOAP messages.

soapmaxconnectionsperhost - The maximum number of concurrent connections that OAM Federation can open when sending SOAP messages to a specific provider.

soapsockettimeout - The default socket timeout (SO_TIMEOUT) in milliseconds which is the timeout for waiting for data. A timeout value of zero is interpreted as an infinite timeout.

soapconnectiontimeout- Sets the timeout until a connection is established. A value of zero means the timeout is not used.

You can use WLST cmd to set the above properties. For example, putLongProperty ("/fedserverconfig/{PropertyName}", {Value}).

Specific Use Cases That Require Additional Tuning for Identity Federation

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

Parent topic: Tuning Oracle Access Management Identity Federation

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

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 Administering Oracle Access Management.

Parent topic: Oracle Access Management Performance Tuning

Basic Tuning Considerations for Security Token Service

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

Parent topic: Tuning Oracle Access Management Security Token Service

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.

Tuning Outbound 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

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 Tuning the Data Tier Connections, and review the tuning parameters discussed in Table 12-3 and Table 12-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.

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.

Parent topic: Tuning Oracle Access Management Security Token Service

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

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

Parent topic: Oracle Access Management Performance Tuning

Basic Tuning Considerations for Mobile and Social

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

Parent topic: Tuning Oracle Access Management Mobile and Social

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

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

Database Tuning for Oracle Access Management

This section describes the tuning process for the OAM Database.

Parent topic: Oracle Access Management Performance Tuning

Automatic Optimizer Statistics Collection

Ensure that this is performed where AM_SESSION table has data. Normally this table will have data during the working hours. Automatic Optimizer Statistics Collection Job should be configured to run at a time when this table has data. Configuring to run at midnight or off peak hours may cause the wrong statistics to be collected and in turn cause performance degradation of the OAM servers.

Follow the procedure below to check the job details.

  1. Connect as dba and run the query.

  2. select * from dba_autotask_client where client_name = 'auto optimizer stats collection'

Parent topic: Database Tuning for Oracle Access Management

Partitioning AM_SESSION table using Config Utility Command

By default, the AM_SESSION table is not partitioned.

It is recommended to partition the AM_SESSION table for stability when high load is expected on the system. Also, the database statistics should be gathered at regular intervals to ensure that queries on the AM_SESSION table perform well.

Run the following Config utility command to partition or non-partition the AM_SESSION table:

java -cp $MW_HOME/idm/oam/server/tools/config-utility/config-utility.jar:$MW_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME createAMSessionTable /scratch/config.properties

The following line should be a part of the properties file (/scratch/config.properties) along with other default properties required for executing config utility commands:

oam.sessionTable.type=<value>

Where <value> should be one of the following:

  • PARTITIONED - To partition AM_SESSION table

  • NON-PARTITIONED - To use non-partitioned AM_SESSION table

Parent topic: Database Tuning for Oracle Access Management

Purging Inactive Sessions as a Recovery Mechanism from Peak Load

Following is the sample REST API:

Method: POST Path: https://oam-policy-admin-host:oam-policy-admin-port/oam/services/rest/access/api/v1/sme/purge?allInactiveSessions=true

Note:

This operation should be executed only during a maintenance or low load window (For example: midnight). You must ensure that following conditions are met:

  • AM_SESSION table is partitioned.
  • Heavy load was observed in current day.
  • Heavy load is anticipated in upcoming days.

If the peak load is expected only for a very short duration in a day, you should not perform this operation. The performance will be optimal with right tunings in place.

Parent topic: Oracle Access Management Performance Tuning