2 Planning Oracle Identity Federation Deployment

This chapter outlines Oracle Identity Federation deployment considerations and helps you understand installation options. It contains these sections:

2.1 Architecture Options

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:

2.1.1 Role in Federation

As described earlier, an Oracle Identity Federation instance in a federated network can serve as an identity provider (IdP), a service provider (SP), 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 identity provider for authentication. Oracle Identity Federation uses 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 authenticates the user and provides the requested application.

Service Provider Role

A user tries to access a resource protected by an authentication engine such as Oracle Single Sign-On, which redirects the user to Oracle Identity Federation. In a service provider 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.

Federation Topology

A federation can comprise any number of identity providers and service providers. One common federation topology is referred to as the hub-and-spoke model. In this topology, there is either a single service provider accepting authentication from multiple identity providers, or a single identity provider authenticating to multiple service providers.

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

Surrounding text describes Figure 2-1 .

2.1.2 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 fire wall, 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 Appendix B, "Using Oracle HTTP Server as 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.

2.1.3 Server Security

Oracle Identity Federation provides secure communication using:

2.1.3.1 SSL Encryption

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 configuration, see Section 8.1.1.1, "Setting up SSL on Oracle WebLogic Server"

2.1.3.2 Certificate-based Authentication

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.

2.1.3.3 Certificate Repository and Validation

Oracle Identity Federation provides a repository where you can store a list of trusted CAs and certificate revocation lists (CRLs).

If certificate validation is enabled for the server, Oracle Identity Federation will validate every certificate used to verify incoming signatures for the SAML and WS-Federation 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:

2.1.4 Protocol

When installing Oracle Identity Federation, you must decide the federation protocols that your server will support. Oracle Identity Federation works with these protocols:

  • SAML 1.0

  • SAML 1.1

  • SAML 2.0

  • WS-Federation

  • OpenID

As the Oracle Identity Federation administrator, you must determine which federation protocols you will utilize for your server.

For more information, refer to Section 1.1.4, "Federation Protocols".

2.2 Profiles and Bindings

This section discusses profiles and bindings, and contains these topics:

2.2.1 Supported Protocols

Having selected the protocol(s) your federation server instance will support, you must choose which protocol profiles, security transport bindings, and other features you will implement. This section outlines Oracle Identity Federation protocol support.

2.2.1.1 SAML 2.0 Protocol

Table 2-1 shows the SAML 2.0 protocol profiles and security transport binding combinations that Oracle Identity Federation supports.

Table 2-1 Oracle Identity Federation Profiles and Bindings for SAML 2.0

Function Profiles/
Bindings		 SAML 2.0

Single Sign-On

Artifact

x

Single Sign-On

HTTP Post

x

Logout

HTTP Redirect

x

Logout

HTTP Post

x

Name ID Registration

HTTP Redirect

x

Name ID Registration

HTTP Post

x

Name ID Registration

SOAP

x

Federation Termination

HTTP Redirect

x

Federation Termination

HTTP Post

x

Federation Termination

SOAP

x

Attribute Retrieval

SOAP

x

2.2.1.2 SAML 1.x and WS-Federation Protocol

Table 2-2 shows the SAML 1.x and WS-Federation (WS-Fed) protocol profiles and security transport binding combinations that Oracle Identity Federation supports.

Table 2-2 Oracle Identity Federation Profiles and Bindings for SAML 1.x and WS-Federation

Function Profiles/
Bindings		 SAML 1.0/1.1 WS-Federation

Single Sign-On

Artifact

x

  

Single Sign-On

HTTP Post

x

x

Logout

HTTP Redirect

  

x

2.2.1.3 OpenID 2.0 Protocol

Oracle Identity Federation supports OpenID version 2.0.

Authentication

Oracle Identity Federation supports basic OpenID authentication request functionality.

Associations

Oracle Identity Federation supports provider federations using an HMAC shared secret for message signing and verification, including:

  • HMAC-SHA1

  • HMAC-SHA256

Oracle Identity Federation supports these session association types:

  • No encryption

  • Diffie-Hellman SHA1

  • Diffie-Hellman SHA256

Discovery

Oracle Identity Federation supports:

  • metadata publishing for OpenID Provider (OP) and Relying Party (RP)

  • XRDS discovery of OPs by the RP

RP endpoint validation is implemented to defend against URL redirectors spoofing RPs to capture OpenID assertions. The RP endpoint validation by the OP is implemented by:

  • XRDS discovery of the RP, checking that the endpoint is listed in the XRDS documented hosted at the realm URL

  • ·Verification using the Realm as described by the OpenID specifications. The realm can either be a URI or a matching domain (*.foo.com for example). At verification, the server extracts the domain from the realm and attempts to match it to the RP endpoint. A valid domain used for verification needs to contain at least two elements (.foo.com is acceptable while .com is not). Additionally, the server provides a way to specify which domain should be discarded (for example *.co.uk).

Account Linking

Oracle Identity Federation supports persistent account linking between OpenID claimed ID and local user account by using a federation data store.

Assertions

Oracle Identity Federation supports assertion-to-user record mapping on the SP side.

Pseudonyms

Oracle Identity Federation uses opaque, persistent name identifiers in OpenID assertions. This means that:

  • a federation data store is required on the IdP side

  • a federation data store is optional on the SP side: if the SP is configured to use Federated Identity to map the assertion to a user, then the federation data store is required.

Profiles and Extensions

Table 2-3 shows the protocol profiles and extensions that Oracle Identity Federation supports.

Table 2-3 Oracle Identity Federation Profiles and Extensions for OpenID 2.0

Profile/Extension Notes

Attribute Exchange (AX) extension

v. 1.0 supported

Provider Authentication Policy Extension (PAPE)

v. 1.0 supported

ICAM profile

Support for No Personal Identification Information, ·Private Personal Identifier, ·GSA Profile for OpenID, and ·NIST authentication levels

2.2.2 Choosing a Profile

This section describes considerations to keep in mind when selecting a profile to implement for the selected protocol:

  • Under the SAML 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.

  • Under the OpenID protocol, you can select the ICAM profile, AX extension, or PAPE extension.

This section discusses:

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-2 shows the process by which requests are processed under the artifact profile.

Figure 2-2 Artifact Profile Processing Flow

Surrounding text describes Figure 2-2 .

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-3, 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 Appendix B, "Using Oracle HTTP Server as a Proxy for Oracle Identity Federation".

Figure 2-3 Artifact Profile Processing with Proxy

Surrounding text describes Figure 2-3 .

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

  • 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 Section 2.6, "Sizing Guidelines" for performance tips.

POST Profile Request Processing

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

Figure 2-4 POST Profile Processing

Surrounding text describes Figure 2-4 .

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-5 illustrates this preferred approach for using the POST profile in production, with Oracle Identity Federation serving as the SP in the DMZ:

Figure 2-5 POST Profile with a Proxy

Surrounding text describes Figure 2-5 .

See Also:

For more information about setting up a proxy server for Oracle Identity Federation, see Appendix B, "Using Oracle HTTP Server as 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.2.2.3 SAML Security Considerations

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

    • With SHA-1 for signature generation

    • With SHA-1 or SHA-256 for signature verification

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

  1. SSL is required for redirection from the IdP to the user's browser, and for redirection from the browser to the SP.

  2. The SOAP channels used by the IdP and SP to communicate directly must be protected either by using SSL or by using HTTP Basic Authentication.

Note:

It is also possible for the SP to 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:

  1. Secure HTTP (HTTPS) is required to transmit a user request from a browser to the service provider.

  2. The identity provider must use an XML signature to sign responses it sends to a service provider.

  3. The service provider must verify the XML signature on the response.

2.2.2.4 Using the SAML Attribute Sharing Profile

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 implementations at peer sites. For details about components and their respective roles, and how to configure Oracle Identity Federation and Oracle Access Manager, see Section 5.6.4.3, "Configuring an Oracle Access Manager Policy using Attribute Sharing".

2.2.2.5 Using the WS-Federation Logout Profile

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.

2.2.2.6 Using OpenID Profiles and Extensions

This section describes Oracle Identity Federation support for different OpenID profiles and extensions.

Attribute Exchange (AX)

AX is an OpenID 2.0 extension allowing user attributes to be requested and returned. OIF supports AX version 1.0.

Support on the IdP includes the following:

  • Profile support is enabled on the IdP, but for each SP, you must indicate whether attributes should be sent

  • Attribute definition is achieved through the existing screen on the SP Partner specific page

Support on the SP includes the following:

  • Attribute definition is achieved through the existing screen on the IdP Partner specific page

  • In the attribute definition page, you can specify which attributes to request from the IdP when performing the SSO protocol.

  • A custom SP engine or a pre-processing engine can dictate at run-time which attributes must be requested from the IdP when performing the SSO protocol.

Provider Authentication Policy Extension (PAPE)

PAPE is an OpenID 2.0 extension allowing RPs to request specific authentication type/strength, including Levels of Assurance. Oracle Identity Federation supports PAPE version 1.0.

Support on the IdP/OP includes the following:

  • The IdP publishes in the XRDS document whether or not the PAPE extension is enabled.

  • If enabled, the IdP includes the authentication mechanism used to authenticate the user in the response to the SP.

Support on the SP/RP includes the following:

  • If the IdP supports PAPE, and if configured to request a specific authentication mechanism, the SP indicates the mechanism to use to authenticate the user at the IdP.

Note:

The Oracle Identity Federation authentication mechanism is translated to OpenID authentication methods.

US Government Federal Identity, Credentialing and Access Management (ICAM) Profile

Oracle Identity Federation supports these privacy policy and security requirements for the US Government for OpenID 2.0 deployments:

The following are deprecated:

  • ICAM OpenID 2.0 Profile

Note:

While these profiles can be enabled on Oracle Identity Federation, you must ensure that the federation server complies with the requirements.

OpenID Profile Request Processing

Figure 2-6 shows the request processing under the OpenID profile:

Figure 2-6 OpenID Processing Flow

Surrounding text describes Figure 2-6 .

2.3 Authentication Engines

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:

  1. Oracle Identity Federation provides support for WS-Federation, Liberty 1.x, SAML 1.0/1.1, SAML 2.0, and OpenID protocols.

  2. An authentication module provides support for user authentication and integration with IdM solutions.

To support these operations, 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:

2.3.1 Engines in Oracle Identity Federation

Oracle Identity Federation interacts with two distinct modules when performing User Federation operations:

  • The authentication engine 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 Single Sign-On.

  • The Oracle Identity Federation SP integration engine 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 this deployment, the authentication module interacts directly with a number of repositories and IdM solutions to enable Oracle Identity Federation to locally authenticate the user:

  • an RDBMS repository

  • an LDAP repository

Figure 2-7 Authenticating with a Repository in IdP Mode

Surrounding text describes Figure 2-7 .

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 user enters credentials (Step 5), when

  • the authentication module prompts the user for credentials (Step 6)

  • 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 Oracle Single Sign-On IdM solution or Oracle Access Manager to enable Oracle Identity Federation to authenticate in IdP mode.

Figure 2-8 Authenticating with an IdM Solution in IdP Mode

Surrounding text describes Figure 2-8 .

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 Propagating Authentication State to Oracle Access Manager 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 so that the user can access the requested resource, which is protected by WebGate (for an Oracle Access Manager IdM deployment).

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

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

Surrounding text describes Figure 2-9 .

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

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

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

2.3.5 Propagating Authentication State to Oracle 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 Oracle 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 Oracle Single Sign-On in SP Mode

Surrounding text describes Figure 2-10 .

The flow for authenticating a user at a peer provider with Oracle 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 Oracle Single Sign-On with the user identification (Steps 5,6).

  • Oracle 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 Oracle Single Sign-On protect resources and either component can be the authentication mechanism, see "Integrating with Oracle Identity Federation" in Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.

2.3.6 HTTP Basic Authentication

Oracle Identity Federation can be configured to accept HTTP basic credentials without requiring an identity and access management system. This corresponds to using the JAAS authentication engine.

2.4 Data Repositories

This section describes installation requirements to enable Oracle Identity Federation to work with data stores. It contains these topics:

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

  • Microsoft Active Directory

  • IBM Tivoli

It also supports XML stores, databases, and a None option (no repository) for SAML and WS-Federation 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

    • Oracle Directory Server Enterprise Edition: 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

    • Oracle Directory Server Enterprise Edition: 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 must be compatible. In the User Federation Record Context, the administrator specifies 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 must 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 are 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:

  1. Choose the Advanced Installation mode.

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

  3. On the "Specify Federation Data Store" page, enter the LDAP connection information. The schema is then 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/userFedSchemaSunOne5.ldif if you use the Oracle Directory Server Enterprise Edition 5.x

  • $Oracle_Home/fed/setup/ldap/userFedSchemaSunOne6.ldif if you use the Oracle Directory Server Enterprise Edition 6.x

  • $Oracle_Home/fed/setup/ldap/userFedSchemaAD.ldif if you use Microsoft Active Directory Server. In this case, you must 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

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

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

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

    • Oracle Directory Server Enterprise Edition: 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

    • Oracle Directory Server Enterprise Edition: 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

    • Oracle Directory Server Enterprise Edition: 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

Collect the following information about the repository prior to installing Oracle Identity Federation:

  • JNDI Name - references the data source configured in Oracle WebLogic Server pointing to the RDBMS to use to authenticate/locate users. You must define this data source after Oracle Identity Federation installation, prior to authenticating any users.

  • Login Table - the RDBMS table containing the user information used for authentication and lookups

  • User ID Column - the RDBMS column in the login table containing the user identifiers

  • 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 Session and Message Data Stores

Oracle Identity Federation also maintains transient session and message data stores for federation session/protocol state. This data can be stored in either in-memory tables or a relational database.

RDBMS session and message data stores are required for high-availability and clustering support.

2.4.4 Configuration Data Store

Configuration data for Oracle Identity Federation can be stored in either XML files or a relational database.

An RDBMS configuration data store is required for high-availability and clustering support.

2.5 Installation Requirements

This section explains installation requirements.

Note:

Liberty 1.x support is deprecated.

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 WebLogic Server

  • A user identity data store. This is typically an LDAP directory, but can optionally be a database store.

    See Also:

    Oracle Fusion Middleware Security Overview for more information, including a list of supported stores.

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

  • One of these versions of Oracle Database for the RDBMS transient data store:

    • Oracle Database 10.2.0.4 or higher

    • Oracle Database 11.1.0.7 or higher

    • Oracle Database 11.2.x

    Note:

    Check the certification matrix for the most current version information.

  • Oracle HTTP Server for proxy implementation; this is the only proxy server supported by Oracle Identity Federation, and is bundled with the installation.

2.6 Sizing Guidelines

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:

2.6.1 Deployment and Architecture Considerations

Before deploying Oracle Identity Federation, you must define the architecture and role that Oracle Identity Federation will play in a federated authentication setting. Here are some decisions that you must 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.

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

    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:

2.6.1.1 Profiles

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.

2.6.1.2 Repositories

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 back-end identity and access management system, the AccessGate performance considerations apply, as do the Access Server sizing considerations outlined here:

    http://docs.oracle.com/cd/E15217_01/doc.1014/e12490.pdf

2.6.1.3 Transient (Session and Message) Storage

Place the transient data store in memory for improved performance.

2.6.1.4 Security for Assertions

Performance can be sensitive to the presence or absence of digital signatures/encryption in the SAML assertions. While removing these features can improve performance, it is not recommend if the IdP and SP communication takes place over the internet.

2.6.1.5 Connection Tuning

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 Oracle Identity Federations interact directly with each other using the SOAP protocol)

2.6.1.6 High Availability

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 the Oracle Fusion Middleware High Availability Guide.

2.6.1.7 Tuning Servers

Take into account the presence of other servers in your production environment. Specifically, consider:

See Also:

The following provide tuning and performance guidelines:

2.6.1.8 HTTP Session Persistence

Oracle Identity Federation uses HTTP session state during request processing. To configure Oracle WebLogic Server session persistence see the chapter titled "Using Sessions and Session Persistence" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle.

By default, memory-based storage is used. If you do not allow sufficient heap size when running Oracle WebLogic Server, your server may run out of memory under heavy loads.

2.6.1.9 Impact of Additional Security

Introducing additional security measures, such as fire walls, proxy servers, or using SSL authentication, can add extra steps in federated transactions and therefore impact performance.

2.6.2 Typical Deployment Scenario

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.

Figure 2-11 A Typical Federation Deployment Architecture

Surrounding text describes Figure 2-11 .

2.6.3 Reference Server Footprint

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. See the certification matrix for a list of certified platforms for Oracle Identity Federation.

    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.

2.6.4 Topology

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.

Figure 2-12 Sample Topology for Oracle Identity Federation

Surrounding text describes Figure 2-12 .

2.7 Implementation Checklist

The following checklist summarizes the key items for planning an Oracle Identity Federation installation and provides the essential starting point for deployment.

Note:

Liberty 1.x support is deprecated.

Table 2-4 Implementation Checklist

Planning Item Recommended / Proposed Value Notes



Architecture/Basic Configuration

    

role played

  

IdP, SP, or both

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

LDAP server port number

  

for example, 389

LDAP server access credentials

  

for example, Bind DN = {cn=orcladmin}, Password = {mysecret}

Base DN

  

for example, dc=mydomain,dc=com

federation record context

  

for example, cn=fed,dc=mydomain,dc=com

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.

Configuration data store

  

Specify repository for transient data: RDBMS or File
     

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 for SSL

  

For information about setting up SSL, see Section 8.1, "Configuring SSL for 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 Oracle Fusion Middleware Performance and Tuning Guide.

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.