This chapter provides guidelines for tuning and sizing the services that make up an Oracle Access Management 11g Release 11.1.2 installation.
Section 25.2, "Performance Considerations for Oracle Access Management Services"
Section 25.3, "Tuning Oracle Access Management Access Manager"
Section 25.4, "Tuning Oracle Access Management Identity Federation"
Section 25.5, "Tuning Oracle Access Management Security Token Service"
Section 25.6, "Tuning Oracle Access Management Mobile and Social"
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.
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.
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":
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. |
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.
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.
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.
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.
Tuning your Web application's server is essential to maintaining optimal performance for Access Manager. This section describes tuning configurations for the following:
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 |
|---|---|
|
|
A value of zero in the |
|
|
The total amount of time it takes to receive a GET request. |
|
|
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 Setting |
|
If |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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 |
|---|---|
|
|
Maximum number of connections that this Access Manager Agent can establish with all the Access Manager Servers. |
|
|
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.
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.
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.
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.
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.
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.
The following server caches can be tuned to improve Access Manager performance:
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.
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.
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". |
See Also:
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.
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
Locate and open the desired 10g or 11g Webgate registration page in the Oracle Access Management Console.
Set the Maximum Cache Elements parameter as desired.
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
Locate and open the desired 11g Webgate registration page in the Oracle Access Management Console.
In User Defined Parameters, add or update maxAuthorizationResultCacheElems as desired.
Restart Webgate Web server.
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.
Locate and open the desired 10g or 11g Webgate registration page in the Oracle Access Management Console.
Set the Cache Timeout parameter as desired.
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
Locate and open the desired 11g Webgate registration page in the Oracle Access Management Console.
In User Defined Parameters, add or update authorizationResultCacheTimeout as desired.
Restart Webgate Web server.
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
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.
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.
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.
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
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.
Add the InactiveReconfigPeriod parameter as a user-defined parameter on the Webgate registration page.
Specify the value for InactiveReconfigPeriod in minutes.
Apply your changes to the Webgate registration page.
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.
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
This section describes some specific use cases that require specialized tuning, in addition to the Basic Tuning Considerations for Access Manager.
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.
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.
The following sections describe basic tuning configurations that you should also consider while tuning Identity Federation:
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.
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
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 |
|---|---|
|
|
Execution interval for the asynchronous thread manager |
|
|
Sleep interval for the asynchronous thread manager, to check if execution should occur |
|
|
Size of the queue containing RDBMS operations of the same type (create session, create artifact…) NOTE: It is important to size the |
|
|
Sleep time before the calling thread can retry to add an operation to a queue, in case the queue is full |
|
|
Number of retries when trying to add an operation to the queue |
|
|
Number of default threads in the RDBMS thread executor module for RDBMS asynchronous operations |
|
|
Maximum amount of time to keep the extra threads in the RDBMS thread executor module for RDBMS asynchronous operation |
|
|
Maximum number of threads in the RDBMS thread executor module for RDBMS asynchronous operation
|
|
|
Thread policy of the RDBMS thread executor module for RDBMS asynchronous operation |
|
|
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:
| Parameter | Description |
|---|---|
|
RDBMS Artifact memory cache settings, used in conjunction of the RDBMS asynchronous module: |
|
|
|
Time to live in the memory cache |
|
|
Maximum number of time to retry to locate an entry in RDBMS before returning a failure |
|
|
Sleeping time between retrying lookup operations |
|
RDBMS Memory cache settings (except for Artifact): |
|
|
|
Size of the cache |
|
|
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 |
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.
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.
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.
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.
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.
This section describes some specific use cases that may benefit from additional tuning.
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
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.
The following sections describe basic tuning configurations that you should also consider while tuning Security Token Service:
To optimize Security Token Service performance, follow the Load Balancer and HTTP Server tuning guidelines discussed in Tuning the Web Tier for Access Manager.
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
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.
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.
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
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
The following sections describe basic tuning configurations that you should also consider while tuning Mobile and Social:
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 |
|---|---|
|
|
Use the following steps to configure the maximum number of connections provided for the Access Management server:
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. |
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".