2 Planning Oracle Identity Federation Deployment

2.1.1 Role in Federation

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.

2.1.2 Topology

You can install Oracle Identity Federation in one of two network configurations:

• Hub-and-Spoke

• Peer-to-Peer

2.1.2.1 Hub-and-Spoke

In a hub-and-spoke network, multiple sources (identity providers) communicate with a single destination (service provider).

Figure 2-1 A Hub-and-Spoke Federation Network

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.

2.1.2.2 Peer-to-Peer

In a peer-to-peer network, multiple domains serve as hubs.

Figure 2-2 A Peer-to-Peer Federation Network

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.

2.1.3 Proxy Server

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.

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.

2.1.4 Server Security

Oracle Identity Federation provides secure communication using:

• SSL Encryption

• Certificate-based Authentication

• Certificate Repository and Validation

2.1.5 Protocol

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:

• "Federation Protocols"

• "Liberty ID-FF 1.1" and "Liberty ID-FF 1.2"

2.2.1 Supported Protocols

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.

2.2.2 Choosing a Profile

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:

• Using the Artifact Profile

• Using the POST Profile

• SAML Security Considerations

• Using the SAML Attribute Sharing Profile

• Using the WS-Federation Logout Profile

2.2.2.1 Using the Artifact Profile

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.

Figure 2-3 Artifact Profile Processing Flow

The processing flow takes this path:

1. A user performs a request at Oracle Identity Federation (acting as the IdP).

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

   
   

3. The server redirects the user to the peer site with the artifact. The artifact profile is used to carry the message.

4. The peer site decodes the artifact and deduces that Oracle Identity Federation is the originating site.

5. The peer site contacts the IdP Oracle Identity Federation, sends the artifact and asks the server to dereference it.

6. Oracle Identity Federation retrieves the message from the repository using the artifact.

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

Figure 2-4 Artifact Profile Processing with Proxy

The processing flow is as follows:

1. A user issues a request at the Oracle Identity Federation IdP server.

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

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

4. The proxy forwards the request to the Oracle Identity Federation SP server.

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

6. The proxy forwards the request to the IdP.

7. The IdP retrieves the message from the repository using the artifact, and sends it to the SP.

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

2.2.2.2 Using the POST Profile

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, using the POST profile can affect performance.

POST Profile Request Processing

Figure 2-5 shows the process by which requests are processed under the POST profile:

Figure 2-5 POST Profile Processing

The processing flow is as follows:

1. The user initiates a request, and must be authenticated before the request can be processed.

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

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

4. The service provider extracts the assertion, and creates a user session for the assertion.

5. The service provider sends the user's browser a redirect to the requested resource.

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

Figure 2-6 POST Profile with a Proxy

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:

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

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

3. The user's browser posts the form to the SP's proxy receiver service URL.

4. The proxy forwards the form to the SP's receiver service.

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

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

2.3.1 Authentication Methods in Oracle Identity Federation

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.

2.3.2 Authenticating with a Repository in IdP Mode

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

• eTrust SiteMinder

Figure 2-7 Authenticating with a Repository in IdP Mode

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

2.3.3 Authenticating with an IdM Solution in IdP Mode

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.

Figure 2-8 Authenticating with an IdM Solution 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).

2.3.4 Authenticating with Oracle Access Manager or eTrust SiteMinder in SP Mode

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 eTrust SiteMinder so that the user can access the requested resource, which is protected by WebGate (for an Oracle Access Manager IdM deployment) or eTrust SiteMinder Web Agent (for an eTrust SiteMinder deployment).

The request originates at a peer IdP, and Oracle Identity Federation authenticates in SP mode.

Figure 2-9 Authenticating with Oracle Access Manager or eTrust SiteMinder in SP Mode

The flow for authenticating a user at a peer provider with Oracle Access Manager or 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/eTrust SiteMinder server to create an Oracle Access Manager/SiteMinder authenticated session (Step 5).

• The authentication module redirects the user to the protected resource (Step 6).

• WebGate or the eTrust SiteMinder Web Agent grant the user access to the protected resource (Step 7).

2.3.5 Authenticating with OracleAS Single Sign-On in SP Mode

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.

Figure 2-10 Authenticating with OracleAS Single Sign-On 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).

2.4.1 Federation Data Store

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.

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.

2.4.2 User Data Store

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

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

2.4.3 Transient Data Store

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.

2.5.1 Required Components

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.

2.5.2 Supported platforms

Refer to the Oracle Application Server/OC4J certification matrix for information about platforms and components supported by Oracle Identity Federation.