25 Oracle Access Management Performance Tuning

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:

• Tuning the Oracle HTTP Server

• Tuning Access Manager Webgate

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.

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

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

coherence.distributed.threads in oam-confgi.xml must be set to a minimum of 16.

Coherence monitoring is current disabled by default in the OAM Server. To enable Remote Monitoring of Coherence over JMX, do the following:

1. In the oam-config.xml file of the server, locate the configuration element at the path /DeployedComponent/Server/NGAMServer/Profile/CoherenceConfiguration/ServerTypeSettings/AdminServer. Verify that a child element Management exists. If it does not exist, create one as follows:

   <Setting Name="Management" Type="htf:map">
   <Setting Name="Key" 
   Type="xsd:string">oam.coherence.management</Setting>
   <Setting Name="Value" Type="xsd:string">all</Setting>
   </Setting>
   

   Remove any other "Management" element that may exist in the configuration file.

2. Locate the element "RemoteManagement" in the configuration file. It will exist as follows:

   <Setting Name="RemoteManagement" Type="htf:map">
   <Setting Name="Key"
   Type="xsd:string">oam.coherence.management.remote</Setting>
   <Setting Name="Value"
   Type="xsd:boolean">false</Setting>
   </Setting>
   

   Change the value of the Value element to true.

3. For the changes to take effect, you can increment the value of the "Version" element of the configuration or restart the OAM Servers.

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

• Introducing Webgate Caches

• Reducing Network Traffic Between Components

• Changing the Webgate Polling Frequency

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

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

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

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

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

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.

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

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

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.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.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-4 and Table 25-5 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.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.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:

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.

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