This chapter provides guidelines for tuning and sizing Oracle Adaptive Access Manager (OAAM). It covers these topics:
Note:
Before tuning Oracle Adaptive Access Manager review and implement the general tuning configurations discussed in Chapter 2, "Top Performance Areas".Oracle Adaptive Access Manager (OAAM) provides real-time or batch risk analysis and adaptive authentication capabilities to actively prevent fraud. Out of the box integrations with Oracle Access Manager (OAM) secure web single sign-on and self-service password management flows with adaptive authentication.
For more information on Oracle Adaptive Access Manager, see Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Effective Oracle Adaptive Access Manager performance tuning starts with a good understanding of its usage and general performance issues. Before you begin tuning Oracle Adaptive Access Manager, review this section as well as the recommendations discussed in Top Performance Areas:
Table 27-1 Oracle Adaptive Access Manager Performance Considerations
|
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 for properly tuning Oracle Adaptive Access Manager. See Performance Planning for more information on using population data to improve performance. |
|
Daily activity usage |
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. |
|
Hardware resources and topology |
Like any application deployed in demanding, real-time environments, proper server sizing and configuration is critical for acceptable Oracle Adaptive Access Manager performance. Ensuring that your hardware is sufficient to prevent bottlenecks is a key factor in performance tuning Oracle Adaptive Access Manager. See Securing Sufficient Hardware Resources for more information on optimizing hardware resources. |
|
Protected applications |
Knowing which applications Oracle Adaptive Access Manager is 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 Oracle Adaptive Access Manager 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. |
To identify performance bottlenecks, you should monitor real-time performance metrics for Oracle Adaptive Access Manager. The following sections describe ways to monitor Oracle Adaptive Access Manager and what you should be monitoring to ensure Oracle Adaptive Access Manager is meeting your performance requirements:
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
Oracle Adaptive Access Manager Admin Console provides a performance dashboard that shows the performance of the traffic that is entering the system. A trending graph is shown of the different types of data based on performance. For more information on accessing and using the Oracle Adaptive Access Manager Admin Console, see "OAAM Admin Console and Controls" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Specifically you should use the dashboard to monitor performance of the following:
Average execution time of Checkpoints (first) and Rules (second) and their trending data.
Response time of APIs and their trending data
Statistics such as the number of logins and transactions can tell you when the system is handling larger numbers of users. This information will help you determine your overall performance strategy.
Consider monitoring the Oracle Adaptive Access Manager Server logs to check for messages related to slow-running SQL statements and errors. For example, If you notice numerous messages that are related to high response times of the SQL statements, then that usually means there are issues in the database. In this case the DBA should look at the database and investigate further to narrow down the issue.
To view the server log files, you can use Oracle Enterprise Manager Fusion Middleware Control or go to the Oracle Adaptive Access Manager home directory and look at the Oracle Adaptive Access Manager Server log files to find these issues.
For more information on using Oracle Adaptive Access Manager Server logs, see "Configuring Logging Output" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
This section provides the basic tuning considerations for Oracle Adaptive Access Manager. It contains the following tuning recommendations:
OAAM uses purge scripts to archive and purge different sets of transactional tables in the OAAM database. Purging releases disk space in the database for current data and deletes obsolete data. The purge process can be based on the age of the data or the type of data. By default OAAM purge scripts will archive data that will be deleted during the purge process. Targeted transaction and entity data archive and purge using the OAAM Admin Console is available in OAAM 11.1.2.
When tuning Oracle Adaptive Access Manager, you must first review the baseline tuning parameters for your database. For more information, see Section 2.6, "Tuning Database Parameters".
To ensure that the Oracle Adaptive Access Manager is performing at the optimal level, it is important to tune the Oracle Internet Directory as described in Chapter 23, "Oracle Internet Directory Performance Tuning".
Oracle Adaptive Access Manager performs best when the following application parameters are set:
To optimize Oracle Adaptive Access Manager, See the Java Virtual Machine tuning recommendations discussed in Section 2.4, "Tuning Java Virtual Machines (JVMs)".
JDBC Datasource OAAM_ADMIN_DS is used by the Oracle Adaptive Access Manager administration server for configuration. JDBC Datasource OAAM_SERVER_DS is used by the Oracle Adaptive Access Manager administration server for customer authentication and other transactional purposes. To increase the capacity of the JDBC connection pools consider the following:
| Parameter | Description |
|---|---|
OAAM_ADMIN_DS |
Set the Initial Capacity to one half of the Maximum Capacity. For example, consider setting the Initial Capacity to 50 and Maximum Capacity to 100. |
OAAM_SERVER_DS |
Set the same value for Initial Capacity and Maximum Capacity. For example, consider setting the Initial Capacity and Maximum Capacity to 100. |
For more information on using the Oracle WebLogic Administration Console to modify connection pools, see "Configure JDBC generic data sources" in the Oracle WebLogic Console online help.
For Oracle Adaptive Access Manager performance testing and production environments, consider using the lowest acceptable logging level whenever possible.
By default, log messages are written to the access.log file only when logging is set to NOTIFICATION:1. To maintain performance, consider keeping the default log level ERROR:1 (SEVERE) or use WARNING:1 (WARNING) to limit the amount of information written to the access.log file.
For more information on tuning the Oracle WebLogic Server log files, see the Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.
The following Oracle Adaptive 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.
If the history of the device is not required, then device history logging can be turned OFF by setting the property bharosa.trackernodehistory.enable to false using Oracle Adaptive Access Manager Admin Console.
By default detailed rule logging takes place whenever a rule takes more than 2000 milliseconds (2 seconds) to execute. This is controlled through the vcrypt.tracker.rulelog.detailed.minMillis property.
The Auto-learning feature tracks transactions and authentications being performed by different actors based on patterns you create. This process establishes what is "normal" or average behavior for an individual or a population. By default, Auto-learning collects data for hourly, daily granularity that is not used by the out-of-the-box patterns. If there are no custom patterns that use hourly, daily granular data, then that data collection can be disabled by setting the following properties to false:
tracker.wf.createHourlyEntries tracker.wf.createDailyEntries
Note:
When auto-learning is disabled, no pattern-based risk analysis will be performed. Consider this before you disable auto-learning as the risk analysis may be an important part of your data collection.This section describes some specific use cases that may benefit from additional tuning.
The following properties and default values are used to create the Oracle Access Manager Client Object Pool. These parameters can be configured to higher values if the login volume is high. Note that any changes to these properties require a restart of the OAAM Server in order to rebuild the connection pool with new settings.
| Parameter | Description | Tuning Consideration |
|---|---|---|
| Primary OAM Server Setting:
oaam.uio.oam.num_of_connections |
Max connections in the pool.
Default is 20. |
Consider increasing the default value to meet your usage requirements. |
| Secondary OAM Server Settings (if used):
oaam.uio.oam.secondary.host.num_of_connections |
Max connections in the pool to secondary server. | Consider increasing the default value to meet your usage requirements. |
| oaam.oam.oamclient.minConInPool | Minimum number of connection in a pool
Default is 20. |
Consider keeping this value the same as the Max Connections set in oaam.uio.oam.num_of_connections |
| oaam.oam.oamclient.initDelayForWatcher | Initial delay for pool watcher thread to start observing the pool.
Default is 300 milliseconds. |
Specify the delay in milliseconds based on your requirements. |
| oaam.oam.oamclient.periodForWatcher | Pool watcher thread sleep duration in milliseconds.
Default is 300 milliseconds. |
Keep this to low value if connections are frequently interrupted. |
| oaam.oam.oamclient.timeout | Duration of connection wait time in milliseconds, if no connections are available in pool.
Default is 60 milliseconds. |
Keep this value to low number whenever possible. |
If Oracle RAC is used to host an Oracle Adaptive Access Manager database, then consider setting the following parameters to improve Oracle Adaptive Access Manager database performance:
Use Reverse Key Indexes for primary keys of the tables to reduce contention:
VCRYPT_TRACKER_USERNODE_LOGS
VCRYPT_TRACKER_NODE
VT_SESSION_ACTION_MAP
Create partitioned indexes on heavily accessed tables to reduce index contention.
In deployments where applications are integrated with Oracle Adaptive Access Manager using SOAP (Simple Object Access Protocol) option, the following should be considered to optimize performance:
Make sure there are no network issues between the SOAP client and Oracle Adaptive Access Manager Server
To reduce DNS resolution issues, specify the IP Address of the Oracle Adaptive Access Manager Server where SOAP services are hosted as the value of Oracle Adaptive Access Manager Host in vcrypt.tracker.soap.url property
If you are using Oracle Adaptive Access Manager offline to perform risk evaluations on historical or non-real time login/transactional data, you may need to complete some additional configurations to ensure performance is maintained. For more information on using Oracle Adaptive Access Manager Offline, see "OAAM Offline" in the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.