| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) Part Number B25355-02 |
|
|
View PDF |
| Oracle® Identity Federation Administrator's Guide 10g (10.1.4.0.1) Part Number B25355-02 |
|
|
View PDF |
This chapter outlines Oracle Identity Federation deployment considerations and helps you understand installation options. It contains these sections:
In planning to deploy Oracle Identity Federation, you should understand the server architecture, the operating environment, and the role that your server will play in a federated exchange network. This section outlines the architectural aspects of Oracle Identity Federation deployment, including:
As described earlier, an Oracle Identity Federation instance in a federated network can serve as an identity provider, a service provider, or both.
Identity Provider Role
When a user wishes to access a protected resource in the federated network, the service provider for that resource directs the user to Oracle Identity Federation, which acts as IdP for authentication. Oracle Identity Federation works with an authentication engine to obtain credentials and authenticate the user. Oracle Identity Federation can now assert the user's identity to the resource (SP), which logs the user in and provides the requested application.
Service Provider Role
A user tries to access a resource protected by an authentication engine such as Oracle Application Server Single Sign-On, which redirects the user to Oracle Identity Federation. In an SP role, Oracle Identity Federation redirects the user to an identity provider such as a portal for global authentication. The IdP portal can now obtain credentials, authenticate the user, and redirect back to Oracle Identity Federation, which then retrieves the asserted identity from the IdP. Oracle Identity Federation redirects the (authenticated) user to the authentication engine, which grants access to the protected resource.
You can install Oracle Identity Federation in one of two network configurations:
In a hub-and-spoke network, multiple sources (identity providers) communicate with a single destination (service provider).
Figure 2-1 shows a hub-and-spoke network in which Company D serves as a destination for companies A, B, C, and E. Company D may offer resources, such as financial services, to which employees of the other companies need access.
Note:
The hub-and-spoke is a topology, in which the source (IdP) or destination (SP) can interchangeably serve as either hub or spoke. Thus the roles in Figure 2-1 could just as well be reversed to depict a network consisting of an IdP hub and SP spokes.In a peer-to-peer network, multiple domains serve as hubs.
Figure 2-2 shows a peer-to-peer network in which company A is a service provider for companies B and C, while Company C is a service provider for Companies D and E. Thus Company C serves as both an identity provider and a service provider. Company E serves as identity provider for users who consume services at Companies A and C.
You must decide what components you will put in the DMZ and whether to use a proxy server. If you put Oracle Identity Federation behind the firewall, the proxy must forward requests and responses to the federation server, enabling transparent access to the server from an external network such as the internet.
Oracle Identity Federation configuration varies depending on the type of profile being implemented.
See Also:
For more information about setting up a proxy server for Oracle Identity Federation, see "Setting Up a Proxy for Oracle Identity Federation"POST Profile with Proxy in SP DMZ
The POST profile sends the full assertion to the SP over HTTPS. Both IdP and SP are configured to communicate through their SSL ports. When using the POST profile in production, the SP uses a proxy server in the DMZ.
Artifact Profile with Proxy in IdP and SP DMZ
When using the browser artifact profile, the IdP sends an artifact (an identifier) rather than an actual assertion. The SP receives the artifact and requests the full assertion thereafter.
If you elect to use a proxy, note that proxies must be used for both IdP and SP in order to implement this profile. The proxies serve as receiver and responder services, handling the exchange of artifacts, assertion requests and assertions, and forwarding those objects to their respective providers.
Oracle Identity Federation provides secure communication using:
Oracle Identity Federation provides secure SSL communication between partner domains. SSL encryption is an option you can enable or disable for the server instance at installation time.
Note:
For more information about SSL and related system security topics, see the Oracle Application Server Security Guide.For initial setup and testing, identity providers and service providers can use default self-signed certificates. Before going into production, however, you will want to ensure that your installation is set up to use third-party CA certificates.
Oracle Identity Federation provides a repository where you can store a list of trusted CAs as well as certificate revocation list (CRL)s.
If certificate validation is enabled for the server, Oracle Identity Federation will validate every certificate used to verify incoming signatures for the Liberty 1.1, Liberty 1.2, and SAML 2.0 protocols.
To validate a certificate, the server tries to locate the certificate or its issuer as a trusted certificate, and checks that the certificate is not in a CRL.
See Also:
"Editing Server Properties" for information about enabling certificate validation
"Editing the Certificate Validation Store" for details about the certificate repository
When installing Oracle Identity Federation, you need to decide the federation protocols that your server will support. Oracle Identity Federation works with these protocols:
Liberty ID-FF 1.1
Liberty ID-FF 1.2
SAML 1.0
SAML 1.1
SAML 2.0
WS-Federation
As the Oracle Identity Federation administrator, you need to determine which federation protocols you will utilize for your server.
For more information, refer to these resources:
This section discusses profiles and bindings, and contains these topics:
Having selected the protocol(s) your federation server instance will support, you must choose which protocol profiles and security transport bindings you will implement.
Table 2-1 and Table 2-2 show the list of supported protocol profiles and security transport binding combinations that can be enabled for an Oracle Identity Federation instance.
Table 2-1 Oracle Identity Federation Profiles, and Bindings for Liberty 1.x and SAML 2.0
| Function | Profiles/Bindings | Liberty 1.1 | Liberty 1.2 | SAML 2.0 |
|---|---|---|---|---|
|
Single Sign-On |
Artifact |
x |
x |
x |
|
Single Sign-On |
HTTP Post |
x |
x |
x |
|
Logout |
HTTP Redirect |
x |
x |
x |
|
Logout |
HTTP Post |
x |
||
|
Name ID Registration |
HTTP Redirect |
x |
x |
x |
|
Name ID Registration |
HTTP Post |
x |
||
|
Name ID Registration |
SOAP |
x |
x |
x |
|
Federation Termination |
HTTP Redirect |
x |
x |
x |
|
Federation Termination |
HTTP Post |
x |
||
|
Federation Termination |
SOAP |
x |
x |
x |
|
Attribute Retrieval |
SOAP |
x |
Under the SAML and Liberty protocols, you can specify whether providers should exchange Oracle Identity Federation assertions using the artifact profile or the POST profile. These profiles represent different methods for secure exchange of assertions.
This section discusses:
Here are some items to keep in mind when considering the artifact profile:
The artifact profile is less resource-intensive than the POST profile because the latter uses XML signatures.
The identity provider's SAML components must reside in the DMZ.
Artifact Profile Request Processing
Figure 2-3 shows the process by which requests are processed under the artifact profile.
The processing flow takes this path:
A user performs a request at Oracle Identity Federation (acting as the IdP).
Oracle Identity Federation authenticates the user and creates an artifact which includes an identifier for the IdP that is known to the SP.
The message to be sent is stored in a repository at the server, with the artifact as a key for retrieval.
Note:
Depending on the installation, the repository may reside either in memory or in a relational database. When using replicated Oracle Identity Federation servers for high availability, the repository must reside in a database.The server redirects the user to the peer site with the artifact. The artifact profile is used to carry the message.
The peer site decodes the artifact and deduces that Oracle Identity Federation is the originating site.
The peer site contacts the IdP Oracle Identity Federation, sends the artifact and asks the server to dereference it.
Oracle Identity Federation retrieves the message from the repository using the artifact.
Oracle Identity Federation sends the message to the peer site for processing.
Note:
This scenario illustrates IdP-initiated single sign-on. When the request is SP-initiated, the user directly requests the resource at the service provider.In contrast with user entries and user federation records, artifact objects are considered as transient data. Because of its transient status, the artifact has a limited lifetime and will be removed from the repository after a certain time.
Artifact Profile With Proxy
As shown in Figure 2-4, you can configure Oracle Identity Federation with proxies for IdP and SP servers when using the artifact profile. In this secure environment, the proxies are located within the DMZ.
See Also:
For more information about setting up a proxy server for Oracle Identity Federation, see "Setting Up a Proxy for Oracle Identity Federation"The processing flow is as follows:
A user issues a request at the Oracle Identity Federation IdP server.
Oracle Identity Federation authenticates the user and creates an artifact which includes a short IdP server identifier. The server redirects the user with the artifact to the receiver service on the SP proxy server.
The user's browser sends the request containing the artifact to the URL of the service provider's receiver service, which is located on the proxy in the SP's DMZ.
The proxy forwards the request to the Oracle Identity Federation SP server.
The SP contacts the IdP's responder service, which is located on the proxy in the IdP's DMZ, sends the artifact, and asks the IdP to dereference it.
The proxy forwards the request to the IdP.
The IdP retrieves the message from the repository using the artifact, and sends it to the SP.
The SP server creates a user session and redirects the user's browser to the desired resource.
For testing purposes, you can configure the peer providers to communicate over open ports. Secure SSL ports are recommended for production, however, and the peer IdP and SP administrators must have exchanged and installed each other's CA certificates. These certificates are used to encrypt and decrypt requests and responses exchanged between the respective federation servers
With the SAML POST profile, the identity provider sends the full assertion to the service provider over HTTPS. While testing, you may wish to configure Oracle Identity Federation without using a proxy.
Note:
The assertion can be sent over HTTP as well. However, it is highly recommend that you always use HTTPS in production environments to ensure the security of the interaction.Here are some items to keep in mind when considering the POST profile:
The POST profile does not require putting your IdP's SAML components in a DMZ.
The SAML components can be placed behind a firewall.
The POST profile requires the use of XML signatures, and signing and verifying signatures is resource-intensive.
If you plan to send or receive large numbers of requests and responses, consider "Sizing Guidelines" for performance tips.
POST Profile Request Processing
Figure 2-5 shows the process by which requests are processed under the POST profile:
The processing flow is as follows:
The user initiates a request, and must be authenticated before the request can be processed.
Oracle Identity Federation - acting as the identity provider - authenticates the user and returns an HTML form containing a response, which consists of an identity assertion and the URL of the service provider. The response is signed using the Oracle Identity Federation IdP's private signing key.
The browser posts this form to the URL of the service provider's receiver service. The receiver service verifies the signed response using the IdP's public certificate associated with its signing key.
The service provider extracts the assertion, and creates a user session for the assertion.
The service provider sends the user's browser a redirect to the requested resource.
The user's browser sends a request to the target resource over the user session created by the service provider.
POST Profile With Proxy
In a secure deployment, the POST profile sends the full assertion to the service provider over SSL. The IdP and SP are configured to communicate over HTTPS through their SSL ports. Figure 2-6 illustrates this preferred approach for using the POST profile in production, with Oracle Identity Federation serving as the SP in the DMZ:
See Also:
For more information about setting up a proxy server for Oracle Identity Federation, see "Setting Up a Proxy for Oracle Identity Federation"The processing flow is as follows:
With Oracle Identity Federation acting as the IdP, the user requests a resource. The SP, an Oracle Identity Federation server, is accessed through a proxy server located in the DMZ.
The IdP server authenticates the user and responds with an HTML form that contains an assertion and the URL of the target resource.
The response is signed using the Oracle Identity Federation IdP's private signing key.
The user's browser posts the form to the SP's proxy receiver service URL.
The proxy forwards the form to the SP's receiver service.
The Oracle Identity Federation SP verifies the signature, extracts the assertion, creates a user session for the assertion, and sends the user's browser a redirect to the resource.
The browser conveys the request to the target resource over the new user session. The request may be handled by an additional proxy located in the service provider DMZ.
SAML provides numerous security features that you can use to ensure privacy, integrity, authenticity, and confidentiality of the SAML messages and the message exchanges.
This section provides a brief summary of message security considerations. For a detailed analysis of the security risks and countermeasures, refer to the OASIS SAML Security Considerations specification, titled Security and Privacy Considerations for OASIS SAML V2.0, at:
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
Oracle Identity Federation supports the full set of security technologies and techniques available for use in a SAML deployment. These include
SSL/TLS for peer authentication and secure communications
XML-SIG for message-level integrity and authentication
XML-ENC for message-level confidentiality
Oracle recommends that secure SSL/TLS channels be used for all SAML message flows in addition to message level security. All communications between an Identity Provider and Service Provider must use bilateral authentication (client and server certificates).
SAML profiles provide specific recommendations on how to securely use SAML assertions and request-response messages in communications protocols. Here are the security requirements for the SAML SSO Artifact and POST profiles.
Secure communication using the SAML Artifact Profile
Secure communication using the SAML artifact profile requires the following:
SSL is required when the IdP communicates with an SP, for redirection from the IdP to the user's browser, and for redirection from the browser to the SP.
The SP's requester service requires a certificate. For SAML 1.0/1.1, the SP requestor may use HTTP basic authentication with a username and password known to the IdP.
Secure communication using the SAML POST Profile
Secure communication using the SAML POST profile requires the following:
Secure HTTP (HTTPS) is required to transmit a user request from a browser to the service provider.
The identity provider must use an XML signature to sign responses it sends to a service provider.
The service provider must verify the XML signature on the response.
The SAML attribute sharing profile is used by service providers to authenticate users by means of SSL client X.509 certificates rather than SAML assertions, when additional user attributes are needed to provide authorization of resource requests.
Oracle Identity Federation provides the attribute sharing profile for use with Oracle Access Manager to enable interoperation with SAML 2.0 implementations at peer sites. For details about components and their respective roles, and how to configure Oracle Identity Federation and Oracle Access Manager, see "Configuring Attribute Sharing" .
WS-Federation can be used to sign into one or more service providers using an identity provider that performs the actual authentication.
To log out, the user clicks on a link at the IdP site that initiates a WS-Federation signout. Using a session cookie, Oracle Identity Federation has kept track of each SP to which the user signed on. The server returns an HTML signout page to the user's browser. Each SP processes the signout cleanup to sign out the session created for Oracle Identity Federation.
Many Oracle Identity Federation features require the user to be authenticated. Such operations include:
IdP protocol operations such as single sign-on, federation creation, federation termination, and NameID registration
SP protocol operations such as federation creation, federation termination, and NameID registration
To gain a perspective on how authentication is effected, we can think of the federation server as comprising these distinct modules:
Oracle Identity Federation provides support for Liberty 1.x, SAML 1.0/1.1, and SAML 2.0 protocols.
An authentication module provides support for user authentication and integration with IdM solutions.
In addition, Oracle Access Manager provides a range of identity administration functions including Web single sign-on, user self-service and registration, policy management, and delegated administration.
In this section we look at the authentication flows these modules enable in different configurations:
The Oracle Identity Federation authentication module can perform two distinct roles in user authentication:
The authentication module acts as a local authentication mechanism. In this mode, the authentication module can authenticate locally with available authentication systems.
Oracle Identity Federation conveys authentication requests to the authentication module. Depending on the deployment, the authentication module may interact directly with RDBMS or LDAP repositories, or it may delegate authentication to an IdM solution such as Oracle Application Server Single Sign-On.
The Oracle Identity Federation authentication module acts to propagate the authentication state. In this mode, Oracle Identity Federation, as a service provider, uses federation protocols to have the user authenticated at a peer identity provider. Oracle Identity Federation then forwards the user to the authentication module, which propagates and creates an authenticated user session in the deployed IdM solution at the SP. In turn, this enables access to the requested protected resource.
Note:
SP mode requires the presence of an IdM solution, while local authentication IdP mode does not require such a solution.In this deployment, the authentication module interacts directly with a number of repositories and IdM solutions to enable Oracle Identity Federation to authenticate in IdP mode:
an RDBMS repository
an LDAP repository
Oracle Access Manager
CA eTrust SiteMinder
The flow for a local authentication involving such a deployment is as follows:
The user accesses Oracle Identity Federation (Step 1).
Oracle Identity Federation forwards the user to the authentication module for local authentication (Step 3).
The authentication module prompts the user for credentials (Step 6).
The user enters credentials (Step 5).
The authentication module interacts with the repository to authenticate the user (Step 7).
The authentication module forwards the user to Oracle Identity Federation with the user's identification (Steps 6,1).
Oracle Identity Federation communicates with the authenticated user (Step 2).
In this deployment, the authentication module delegates authentication to the OracleAS Single Sign-On IdM solution to enable Oracle Identity Federation to authenticate in IdP mode.
The flow for a local authentication involving an IdM deployment is as follows:
The user accesses Oracle Identity Federation (Step 1).
Oracle Identity Federation forwards the user to the authentication module for local authentication (Step 2).
The authentication module redirects the user to the IdM server for authentication (Steps 3,4).
The IdM server authenticates the user and redirects the user back to the authentication module (Steps 5,6).
The authentication module forwards the user to Oracle Identity Federation with the user's identification (Step 7).
Oracle Identity Federation communicates with the authenticated user (Step 8).
In this mode, Oracle Identity Federation uses the federation protocols to identify a user, and requests the authentication module to create an authenticated session at Oracle Access Manager or CA eTrust SiteMinder so that the user can access the requested resource, which is protected by WebGate (for an Oracle Access Manager IdM deployment) or CA eTrust SiteMinder Web Agent (for a CA eTrust SiteMinder deployment).
The request originates at a peer IdP, and Oracle Identity Federation authenticates in SP mode.
The flow for authenticating a user at a peer provider with Oracle Access Manager or CA eTrust SiteMinder is as follows:
The user is at the peer IdP (Step 1).
The IdP redirects the user to Oracle Identity Federation (as SP) with an authentication assertion (Steps 2,3).
Oracle Identity Federation processes the assertion, creates a local Oracle Identity Federation session, and forwards the user to the authentication module with the identification (Step 4).
The authentication module interacts with the Oracle Access Manager/CA eTrust SiteMinder server to create an Oracle Access Manager/CA eTrust SiteMinder authenticated session (Step 5).
The authentication module redirects the user to the protected resource (Step 6).
WebGate or the CA eTrust SiteMinder Web Agent grant the user access to the protected resource (Step 7).
In this mode, Oracle Identity Federation uses the federation protocols to identify a user, and requests the authentication module to create an authenticated session at OracleAS Single Sign-On so that the user can access the requested resource, which is protected by mod_osso.
The request originates at a peer IdP, and Oracle Identity Federation authenticates in SP mode.
The flow for authenticating a user at a peer provider with OracleAS Single Sign-On is as follows:
The user is at the peer IdP (Step 1).
The IdP redirects the user to Oracle Identity Federation (as SP) with an authentication assertion (Steps 2,3).
Oracle Identity Federation processes the assertion, creates a local Oracle Identity Federation session, and forwards the user to the authentication module with the identification (Step 4).
The authentication module redirects the user to OracleAS Single Sign-On with the user identification (Steps 5,6).
OracleAS Single Sign-On creates a local authenticated session and grants access to the resource protected by mod_osso (Steps 7,8).
Note:
For more information about an environment where Oracle Identity Federation and OracleAS Single Sign-On protect resources and either component can be the authentication mechanism, see "Integrating with Oracle Identity Federation" in Oracle Application Server Single Sign-On Administrator's Guide.This section describes installation requirements to enable Oracle Identity Federation to work with data stores. It contains these topics:
You must select a data repository for the persistent federation data store. Oracle Identity Federation works with industry-standard LDAP repositories including Oracle Internet Directory, Sun Java System Directory Server, and Microsoft Active Directory. It also supports a None option (no repository) for SAML 2.0 using non-opaque name identifiers such as e-mail address, X.509 DN, Kerberos, or Windows Name Identifier.
Note:
SAML 1.x and WS-Federation do not require a federation data store.Connection Information
Collect the following information about the repository prior to installing Oracle Identity Federation:
The Connection URL (space-delimited list of LDAP server URLs - hostname and port)
The Bind DN
This is the DN used by the Oracle Identity Federation server to connect to the LDAP server. For example:
cn=fedid,dc=mycompany,dc=com
Password
The User Federation Record Context
This is the node under which all federation records for this Oracle Identity Federation server will be stored.
The LDAP Container Object Class
This is the type of User Federation Record Context that Oracle Identity Federation should use when creating the LDAP container, if it does not exist already. If that field is empty, its value will be set to applicationprocess. For Microsoft Active Directory this field has to be set, to container for example. The appropriate setting for this field depends on the User Federation Record Context being used. (User Federation Record Context is described later in this section).
Here are examples of the LDAP Container Object Class for different types of directory servers:
Oracle Internet Directory: empty
Sun Java System Directory Server: empty
Microsoft Active Directory: container
Unique Federation ID Attribute
This is the LDAP attribute to be used to uniquely identify a federation record. This attribute should be defined in the LDAP Object Class of the Federation Record type, or in its top parent. If it is empty, the default Federation ID attribute will be used as the DN of the Federation Record.
Here are examples of the Unique Federation ID attribute for different types of directory servers:
Oracle Internet Directory: empty
Sun Java System Directory Server: empty
Microsoft Active Directory: empty
Maximum Connections. This is the maximum number of concurrent connections made by Oracle Identity Federation to the LDAP server.
Connection Wait Timeout. This is the maximum number in seconds to wait until a connection is available, when the maximum number of connections opened by Oracle Identity Federation to the LDAP server has been reached.
Relationship of User Federation Record Context and LDAP Container Object Class
The User Federation Record Context and LDAP Container Object Class need to be compatible. In the User Federation Record Context, the administrator will specify the DN of the container where the federation records will be stored. That DN will contain the parent of the container that must already exist (for example dc=us,dc=oracle,dc=com), and an attribute of the Federation Record Context that is part of its object class (for example, cn=orclfed). An example of such DN would be cn=orclfed,dc=us,dc=oracle,dc=com.
The requirement for that example is that cn must be an attribute of the Object Class set in the LDAP Container Object Class field (or the applicationprocess object class if not set).
If the administrator chooses to have the DN of the Federation Record Context like ou=fed,dc=us,dc=oracle,dc=com, she will need to set the LDAP Container Object Class field to an object class that has ou as an attribute, like organizationalUnit.
To summarize, the User Federation Record Context references the LDAP container entry under which federation records will be stored, and the LDAP Container's attribute used in the DN must be defined in the LDAP Container Object Class used. For example, if DN is ou=fed,dc=us,dc=oracle,dc=com, then the LDAP Container Object Class must define the ou attribute; if DN is cn=fed,dc=us,dc=oracle,dc=com, then the LDAP Container Object Class must define the cn attribute.
A Note About the LDAP Schema
The LDAP Schema needs to be upgraded to include the attributes and object classes defined by Oracle Identity Federation, in order for the Federation server to create records in the LDAP server.
Upgrade the LDAP schema either at installation time (with the Advanced Installation mode), or after installation.
Upgrade Schema at Installation
To perform the upgrade at installation time, take these steps:
Choose the Advanced Installation mode.
On the "Select Configuration Options" page, check the "Federation Data in LDAP Server" box. This indicates that the federation records will be stored in an LDAP server whose schema must be upgraded.
On the "Specify Federation Data Store" page, enter the LDAP connection information. The schema will then be upgraded as part of the installation process.
Post-Installation Schema Upgrade
To perform the upgrade post-installation, note that the Oracle Identity Federation installation includes LDIF files that you can execute using the ldapmodify tool to upgrade the schema of an LDAP server.
The LDIF file to use depends on the type of LDAP server used:
$Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif if you use Oracle Internet Directory
$Oracle_Home/fed/setup/ldap/userFedSchemaIPlanet.ldif if you use the Sun One Directory Server
$Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldif if you use Microsoft Active Directory Server. In this case, you need to edit the LDIF file to replace the string %DOMAIN_DN% with your active directory domain suffix.
An example suffix is dc=mydomain,dc=mycompany,dc=com.
$Oracle_Home/fed/setup/ldap/userFedSchemaTivoli.ldif if you use the IBM Tivoli Directory Server (IBM TDS) 6.0
Using ldapmodify, you can upgrade the LDAP schema with the LDIF file. For example:
ldapmodify -c -D BIND_DN_USERNAME -w PASSWORD -f $Oracle_Home/fed/setup/ldap/userFedSchemaOid.ldif -h LDAP_HOSTNAME -p LDAP_PORT -x
You must select a data repository for the user data store. Oracle Identity Federation works with industry-standard repositories including:
LDAP (Oracle Internet Directory, Sun Java System Directory Server, and Microsoft Active Directory)
RDBMS
Oracle Access Manager
OracleAS Single Sign-On
CA eTrust SiteMinder
The role played by the data repository depends on whether Oracle Identity Federation will be configured as an identity provider (IdP) or a service provider (SP):
As an IdP, Oracle Identity Federation uses the repository to verify user identities and to build protocol assertions.
As an SP:
Oracle Identity Federation uses the repository to map information in received assertions to user identities at the destination, and subsequently to authorize users for access to protected resources.
When creating a new federation, Oracle Identity Federation uses the repository to identify the user and link the new federation to that user's account.
Connection Information for LDAP Repositories
Connection information is required for IdM products that use an LDAP directory for their user data, including Oracle Access Manager, OracleAS Single Sign-On, and CA eTrust SiteMinder.
Collect the following information about the repository prior to installing Oracle Identity Federation:
Connection URL - space delimited list of LDAP URLs
Bind DN
Password
User ID Attribute - the attribute name to use to map users during lookups or authentication procedures
Here are examples of the User ID Attribute for different types of directory servers:
Oracle Internet Directory: uid
Sun Java System Directory Server: uid
Microsoft Active Directory: sAMAccountName
User Description Attribute
This field references the user attribute to use as a human readable federation owner identifier. This information will be stored in the federation record.
Here are examples of the User Description Attribute for different types of directory servers:
Oracle Internet Directory: uid
Sun Java System Directory Server: uid
Microsoft Active Directory: sAMAccountName
Person Object Class - the LDAP object class representing a user in the LDAP server
Here are examples of the Person Object Class for different types of directory servers:
Oracle Internet Directory: inetOrgPerson
Sun Java System Directory Server: inetOrgPerson
Microsoft Active Directory: user
Base DN - the node under which LDAP user search will be performed. For example:
dc=us,dc=oracle,dc=com
Maximum Connections - the maximum number of concurrent connections made by Oracle Identity Federation to the LDAP server
Connection Wait Timeout - the maximum number in seconds to wait until a connection is available, when the maximum number of connections opened by Oracle Identity Federation to the LDAP server has been reached
Connection Information for RDBMS Repositories
Connection information is required for CA eTrust SiteMinder, which uses a database for its user repository.
Collect the following information about the repository prior to installing Oracle Identity Federation:
JNDI Name - references the data source configured in Oracle Application Server pointing to the RDBMS to use to authenticate/locate users. You will need to define this data source after Oracle Identity Federation installation, prior to authenticating any users.
User Name
Password
Login Table - the RDBMS table containing the user information used for authentication and lookups
Login ID Column - the RDBMS column in the login table containing the user identifiers
Login Password Column - the RDBMS column in the login table containing the user passwords
Password Digest Algorithm - the hashing algorithm to apply to the input password before matching the result against a value stored in the RDBMS table
User Description Attribute - references the user attribute to use as a human readable federation owner identifier. This information will be stored in the federation record.
Oracle Identity Federation also maintains transient data for federation protocol/session state. This data can be stored in either in-memory tables or a relational database.
An RDBMS transient data store is required for high-availability and clustering support. Note that, in addition to transient session data, server configuration data will be persisted to the database for centralized cluster configuration.
See Also:
For more information, see:This section explains installation requirements, including:
Oracle Identity Federation requires the following components:
Java 2 SDK, Standard Edition (J2SE), Version 1.4.2 (bundled with the installation)
Oracle Containers for J2EE - OC4J (bundled with the installation)
A user identity data store. This is typically an LDAP directory, but can optionally be a database store.
One of these repositories for the user federation data store:
Oracle Internet Directory
Microsoft Active Directory
Sun Java System Directory Server
Note:
A user federation data store is not absolutely required for Oracle Identity Federation in all cases: it is required for Liberty 1.x and SAML 2.0 opaque persistent identifiers, but is optional for SAML 1.x, WS-Federation, and SAML 2.0 non-opaque identifiers (such as email address, subject DN, and so on)Oracle9i Database Server version 10.1.0.3.0 or higher for the RDBMS transient data store
Oracle HTTP Server for proxy implementation; this is the only proxy server supported by Oracle Identity Federation, and is bundled with the installation.
Refer to the Oracle Application Server/OC4J certification matrix for information about platforms and components supported by Oracle Identity Federation.
See Also:
The Oracle Technology Network product page at
http://www.oracle.com/technology/products/index.html.When planning to deploy a federated identity system that leverages Oracle Identity Federation, it is critical to understand the performance considerations, choices, and trade-offs involved in the architecture.
This section considers various factors that have an impact on performance in a federated environment, and provides some guidelines to help you assess hardware requirements for a production system with a standalone Oracle Identity Federation server. The following topics are included:
Before deploying Oracle Identity Federation, you need to define the architecture and role that Oracle Identity Federation will play in a federated authentication setting. Here are some decisions that you will need to make:
Which federation specifications will be used with various trusted partners? Choices include:
SAML 2.0. With additional flows in comparison to SAML 1.x, performance considerations may play a greater role.
Liberty ID-FF 1.1 and 1.2
SAML 1.0 and 1.1
WS-Federation
What profiles will you use to federate with your partners? Options include Browser POST or Artifact profile, WS-Federation Passive Requestor profile, attribute sharing, and others.
Which transport security protocols and certificates will be used? Will the assertions be signed?
What roles will Oracle Identity Federation be playing? Options are:
Identity Provider (IdP), also referred to as a source domain
Service Provider (SP), also referred to as a destination domain
Both IdP and SP
What type (and what vendor's) authoritative identity repositories will be installed?
If deploying Oracle Identity Federation as a Service Provider (SP), consider whether you will deploy an identity and access management (IAM) system to authorize access to protected resources. The overall performance of the solution will be highly dependent on the performance of the IAM system.
Note:
Oracle Identity Federation provides an integration framework that enables you to create lightweight federation endpoints without requiring an access management system.Will you install a proxy server with Oracle Identity Federation? If so, take into account where the Oracle Identity Federation and proxy servers will reside - for example, in the DMZ or behind a firewall.
How will the architecture provide high availability scenarios? Specifically:
Whether you want to support cold failover clusters leveraging the Oracle Application Server High Availability topologies
Whether you want to set up a common assertion store database to make assertion data available to more than one federation server in a load-balancing and failover configuration
The overall throughput and performance of Oracle Identity Federation can depend on a number of factors, such as:
Which profiles are supported (for example, Artifact or POST)
Security features in use (using certificates, digitally signing and/or encrypting assertions)
Use of individual components involved in processing a transaction, such as fire walls, proxy servers, LDAP directories, databases, and IAM systems
The subsequent subsections provide more detail on these topics.
The SAML specification supports a number of profiles, with the two primary deployed profiles being the SAML Browser POST and Artifact profiles. In general, using the SAML Browser POST profile is more performance-friendly than the Artifact profile, as the POST profile requires fewer round trips between the IdP and SP. However, there is a potential security trade-off given that the Artifact profile is, in general, a more secure method of exchanging SAML assertions.
When working with LDAP directories, RDBMS, and back end IAM systems, it is important to pay attention to the transaction processing speed of the component in question, since this can affect the performance of your production environment. Note that:
RDBMS parameters can be tuned to provide options to control database connection pool settings.
If using Oracle Access Manager as the backed identity and access management system, the AccessGate performance considerations apply, as do the Access Server sizing considerations outlined here:
http://www.oracle.com/pls/wocprod/docs/page/ocom/technology/products/id_mgmt/pdf/wp-oracle-idm-sizing-considerations.pdf
Place the transient data store in memory for improved performance. (See "Performance Figures" for an example).
Performance can be sensitive to the presence or absence of digital signatures/encryption in the SAML 2.0 assertions. While removing these features can improve performance, it is not recommend if the IdP and SP communication takes place over the internet.
Pay attention to the proper adjustment of the maximum number of concurrent connections to:
LDAP servers,
the RDBMS (for transient session data and configuration), and
remote providers (when the Oracle Identity Federation servers interact directly with each other using the SOAP protocol)
Also review the settings in the IdM Data Stores -> User Data Store and Federation Data Store.
For greater performance and high availability, consider scaling and load-balancing multiple Oracle Identity Federation servers. Implementing a load-balancing solution provides backup and failover protection for your site.
For details, see "High Availability" and "Setting Up a Load Balancer with Oracle Identity Federation".
Take into account the presence of other servers in your production environment. Specifically, consider:
Tuning Oracle Application Server and setting appropriate connection limits for Oracle Identity Federation. You can:
Tune Oracle Application Server using typical configuration parameters such as memory used, number of processes, and so on. For details, see the Oracle Application Server Performance Guide.
Specify the maximum number of HTTP/JDBC connections that Oracle Identity Federation uses when communicating with remote HTTP servers and RDBMS servers. For details, see "Setting Concurrent Connection Limits" and "Setting JDBC Connection Limits".
Tuning the Oracle HTTP Server, which is leveraged by Oracle Identity Federation. See "Tuning Oracle HTTP Server" for more information.
Figure 2-11 illustrates a typical Oracle Identity Federation deployment architecture for a Service Provider, where Oracle Identity Federation relies on Oracle Access Manager as the back end access management system. The diagram illustrates multiple partners coming in through the DMZ and accessing a load-balanced pair of Oracle Identity Federation Proxy Servers, which are front-ending a pair of Oracle Identity Federation servers.
The following hardware and equipment is recommended for a baseline Oracle Identity Federation deployment, for an environment supporting up to 2000 concurrent users:
Any supported server-class machine and operating system for Oracle Identity Federation. The list of certified platforms for Oracle Identity Federation can be found on the Oracle Application Server 10gR3 (10.1.4.0.1) certification matrix at:
http://www.oracle.com/technology/software/products/ias/files/idm_certification_101401.html
Failover scenarios would double the number of machines required. Use a minimum of two Oracle Identity Federation servers, on separate machines, for redundancy.
Server footprint:
2-4 GB memory (4GB recommended)
Minimum of 2 CPUs per machine
If a proxy server is being used, follow the vendor-specific sizing recommendations.
Figure 2-12 shows the recommended topology for an Oracle Identity Federation deployment in SP mode in which Oracle HTTP Server serves up a provider application that is protected by a webgate.
Using the reference server footprint and topology recommendations as described above, the following performance results have been observed:
Test 1
Transient Store: RDBMS
CPUs: 4
Directory: Oracle Internet Directory
7 OC4J_FED instances both SP and IdP
-Xmx2048 -Dfed.jdbc.min.conn=50 -Dfed.jdbc.min.conn=300
SP OIF -> ko40g OID
IdP OIF -> ko30g OID
SP and IdP User data store ldap connection pool = 300
SP and IdP Federation data store = None (SAML)
SP and IdP OIF transient data in rdbms
SP and IdP HTTP Servers:
MinSpareServers 50
MaxSpareServers 250
StartServers 250
MaxClients 500
AccessGate:
MinSpareServers 5
MaxSpareServers 10
StartServers 100
MaxClients 100
AccessSvr1 -> ko30g OID
AccessSvr2 -> ko40g OID
OID1 and OID2 on port 389:
Result: 125 TPS
Test 2
Transient Store: Memory
CPUs: 4
Directory: Oracle Internet Directory
5 OC4J_FED instances both SP and IdP
-Xmx2048 -Dfed.jdbc.min.conn=50 -Dfed.jdbc.min.conn=300
SP OIF -> ko40g OID
IdP OIF -> ko30g OID
SP and IdP User data store ldap connection pool = 300
SP and IdP Federation data store = None (SAML)
SP and IdP OIF transient data in memory
SP and IdP HTTP Server:
MinSpareServers 50
MaxSpareServers 250
StartServers 250
MaxClients 500
AccessGate:
MinSpareServers 5
MaxSpareServers 10
StartServers 100
MaxClients 100
AccessSvr1 -> ko30g OID
AccessSvr2 -> ko40g OID
OID1 and OID2 on port 389:
orclserverprocs 4
orclmaxcc 4
Result: 240 TPS
Note:
Switching from RDBMS to an in-memory transient store provided a substantial performance gain in the above tests.The following checklist summarizes the key items for planning an Oracle Identity Federation installation and provides the essential starting point for deployment.
Table 2-3 Implementation Checklist
| Planning Item | Recommended / Proposed Value | Notes |
|---|---|---|
|
Architecture/Basic Configuration |
||
|
role played |
IdP, SP, or both |
|
|
topology |
hub-and-spoke or peer-to-peer |
|
|
protocol |
Liberty 1.1, Liberty 1.2, SAML 2.0, or any combination of the three. SAML 1.0, SAML 1.1, and WS-Federation. |
|
|
Repository |
Specify repository for the user data and federation persistent data. |
|
|
LDAP server hostname |
for example, |
|
|
LDAP server port number |
for example, |
|
|
LDAP server access credentials |
for example, |
|
|
Base DN |
for example, |
|
|
federation record context |
for example, |
|
|
federation schema updateFoot 1 |
This information must be provided at the time of installation. |
|
|
transient data store |
Specify repository for transient data: RDBMS or in-memory. |
|
|
IdP Profiles & Bindings |
Use a row for each combination enabled. |
|
|
SP Profiles & Bindings |
Use a row for each combination enabled. |
|
|
SSL Encryption |
||
|
Enabled/Disabled |
||
|
Java keystore |
Specify Java keystore location if using SSL. |
|
|
For information about setting up SSL, see "Using SSL with Oracle Identity Federation". |
||
|
Certificates |
||
|
signing |
Specify location of PKCS #12 wallet for signing key pair. |
|
|
encryption |
Specify location of PKCS #12 wallet for encryption key pair. |
|
|
Performance Planning |
||
|
Topology, Reference Server Footprint |
For performance tips and recommendations, see "Sizing Guidelines" |
Footnote 1 For the federation schema update, collect the Connection URL, the Bind DN, password, User Federation Record Context, the LDAP Container Object Class (Microsoft Active Directory), and Unique Federation ID Attribute.
