Oracle Identity Federation is a standalone, self-contained federation server that enables single sign-on and authentication in a multiple-domain identity network. It contains the following sections:
The configuration examples and recommended settings described in this chapter are for illustrative purposes only. Consult your own use case scenarios to determine which configuration options can provide performance improvements.
Oracle Identity Federation (OIF) is a standalone, self-contained federation server that enables single sign-on (SSO) and authentication in a multiple-domain identity network. The federation single sign-on capabilities are based on the SAML 1.x/SAML 2.0/WS-Fed protocols. The server is a Java EE Application deployed in a WebLogic Managed Server. This enables users to federate in heterogeneous environments and business associations, whether they have implemented other Oracle Identity Management products in their solution set.
For more information see Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
The following tuning considerations are generally applicable to most use case scenarios and can improve Oracle Identity Federation performance.
This section provides configuration settings that can be used to tune the database.
See "Additional RDBMS Configuration" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Oracle Identity Federation uses a Java EE data source to interact with a database for various operations, such as:
Locating a user record in the User Data Store
Retrieving attributes from a user record in the User Data Store
Locating, creating, or deleting an Oracle Identity Federation record from the Federation Data Store
Locating, creating, or deleting an Oracle Identity Federation transient record from the Session or Message Data Store. (A transient record can be a user session, an artifact record, or federation protocol or session state.)
When creating a data source in the WebLogic Administration Console that can be used by Oracle Identity Federation, the maximum and minimum connection settings should be tuned for better performance. Consult your use case scenarios to determine what the connections settings should be to improve performance in your application.
When Oracle Identity Federation is integrated with RDBMS for its Session Data Store, the server uses a caching mechanism to improve performance at run time. This enables the server to keep a reference to recently used session objects in memory to avoid read access to the database.
To optimize RDBMS session caching, configure the following:
Number of session objects kept in memory at a given time
Length of time a specific session object is kept in memory
if Oracle Identity Federation is in High Availability (HA) mode with a load balancer, sticky sessions must be enabled to ensure that the cache is always reflecting accurate data.
See "Configuring RDBMS Session Cache" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
To decrease the amount of data to be stored in an RDBMS, Oracle Identity Federation provides the capability to compress the data before storing it to the database.There are three kinds of data that can be compressed:
AuthnRequest for SSO Artifact profile: when Oracle Identity Federation acts as an IdP for Liberty 1.x protocol, the server stores the
AuthnRequest message in the RDBMS when the artifact profile is used.
Assertion Response for SSO Artifact profile: when Oracle Identity Federation acts as an IdP for SSO protocols, the server stores the Response message containing the Assertion in the RDBMS when the artifact profile is used. This must be enabled if attributes are contained in the assertion.
User Session Data: Oracle Identity Federation stores some session data related to the user at run time. If several attributes are stored in the User Session (set by a custom Authentication Engine, or because the Attributes Assertion storage was enabled when Oracle Identity Federation was a service provider), then compression should be used.
See "Configuring RDBMS Data Compression" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
If Oracle Identity Federation is fronted by Oracle HTTP Server (OHS), then the configuration of the HTTP Server can be tuned to increase performance. For more information on Oracle HTTP Server, see Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server.
The following parameters can be changed in the httpd.conf file of the OHS. For additional Oracle HTTP tuning configurations, see Chapter 6, "Oracle HTTP Server Performance Tuning". Consult your use case scenarios to determine what your settings should be.
After modifying these parameters, save and restart OHS.
The following tuning considerations may or may not apply to your OIF deployment. Review your use case scenarios to determine if these changes can help improve performance:
This section provides configuration settings that can be used to tune LDAP such as:
For the best performance, review the tuning configurations in Chapter 2, "Top Performance Areas" before tuning Oracle Identity Federation.
When Oracle Identity Federation is integrated with LDAP Servers as a user data store, federation data store, or authentication engine, the server keeps a pool of LDAP connections that can be re-used for subsequent requests.
Oracle Identity Federation performs the following kind of operations to the LDAP Servers:
User Data Store
Locate users during assertion mappings
Retrieve attributes from the user record when creating an assertion
Validate user credentials during authentication operations
Federation Data Store, if used
Create a federation record
Locate a federation record
Update or delete a federation record. The LDAP Connection Pool can be configured by:
Setting Maximum Connections to indicate how many LDAP connections can the pool contain.
Setting the Connection Wait Timeout which is the time that a thread waits before re-trying to get an LDAP connection when none are available in the pool and that the pool is at maximum capacity.
See "Configuring Oracle Identity Federation" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation for more information on the User and Federation Stores as well as the LDAP Authentication Engine.
When Oracle Identity Federation is integrated with LDAP Servers as a user data store, federation data store, or authentication engine, the LDAP run time connections can be configured. For more information, see "Configuring Oracle Identity Federation" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
The LDAP Connections can be configured by:
Setting the LDAP Inactivity setting which tells Oracle Identity Federation 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 in Oracle Identity Federation.
See "Configuring the LDAP Inactivity Setting" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
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, Oracle Identity Federation 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. Oracle Identity Federation closes the connection, open a new one and re-issue the LDAP command.
See "Configuring the LDAP Read Timeout Setting" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
Setting the High Availability (HA) LDAP Flag. When integrated with LDAP Servers that are deployed in HA mode, Oracle Identity Federation must configured to indicate that the LDAP Servers are in HA mode.
See "Configuring High Availability LDAP Servers" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
When using Oracle Internet Directory as the Federation Data Store, Oracle Identity Federation creates, locates, updates and deletes federation records containing Account Linking Information.
Oracle Identity Federation uses specific queries when interacting with Oracle Internet Directory, and the performance can be improved by creating filters in Oracle Internet Directory. If Oracle Internet Directory is used as the Federation Data Store, it is possible to tune the LDAP Server to improve the performance of the lookup operations. Oracle Identity Federation server can be configured to use a Federation Store to persist Federated Identities records.
The Federation server uses this store to:
Lookup a federation record through different queries
Create a federation record
Delete a federation
In addition to the Oracle Identity Federation-related
(objectclass=orclfeduserinfo), which is included by default, some Oracle Identity Federation environments might benefit from additional filters with the following formats:
orclfedserverid denotes the Oracle Identity Federation server that is making the query,
orclfedproviderid is the identifier of a remote SAML server, and
1 as the value for
orclfedfederationtype when Oracle Identity Federation is an Identity Provider and the remote provider is a Service Provider. Use
3 when Oracle Identity Federation is a Service Provider and the remote provider is an Identity Provider.
A deployment can be configured to work with many remote SAML servers, so there can be several
orclfedproviderid filters and more than one
The Security Assertion Markup Language (SAML) protocol involves interacting with remote servers through the use of the Simple Object Access Protocol (SOAP).
The Oracle Identity Federation server uses the SOAP protocol to send SAML Requests and to receive SAML Responses.
To optimize performance, configure the following SOAP connections:
Total maximum number of SOAP connections that Oracle Identity Federation can open at the same time
Maximum number of SOAP connections that Oracle Identity Federation can open at the same time to a given remote server
For more information, see "SOAP Binding" in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.
The SAML and WS-Fed protocols of Oracle Identity Federation rely 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 Oracle Identity Federation 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
The content of the Assertion is viewable unless SAML 2 Encryption is used. Encrypting the Assertion is optional, but XML Encryption is resource intensive and decreases performance
There are two Single Sign-On profiles defined by the SAML specifications:
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.
If the performance must be improved and if using the POST profile is compliant with company security regulations, then configuring Oracle Identity Federation to use the POST profile may be an option to improve performance.
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 additional communication flow between the Service Provider and the Identity Provider, performance may be slower when using the Artifact profile.