| Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation 11g Release 1 (11.1.1) E13400-03 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Administrator's Guide for Oracle Identity Federation 11g Release 1 (11.1.1) E13400-03 |
|
Previous |
Next |
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 (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.
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.
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 configuration, see Section 8.1.1.1, "Setting up SSL on Oracle WebLogic Server" |
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 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:
|
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".
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, security transport bindings, and other features you will implement. This section outlines Oracle Identity Federation protocol support.
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 |
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.
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 |
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:
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.
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-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". |
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 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:
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-5 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 Appendix B, "Using Oracle HTTP Server as 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 for redirection from the IdP to the user's browser, and for redirection from the browser to the SP.
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:
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 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".
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.
This section describes Oracle Identity Federation support for different OpenID profiles and extensions.
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:
No Personal Identification Information referenced by the http://www.idmanagement.gov/schema/2009/05/icam/no-pii.pdf URI. When enabled and specified in the protocol exchange, the IdP cannot include any personal information in the response to the SP.
Private Personal Identifier referenced by the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier URI. When enabled and specified in the protocol exchange, the IdP must return an opaque ClaimedID specific to the RP.
GSA Profile for OpenID referenced by the http://www.idmanagement.gov/schema/2009/05/icam/openid-trust-level1.pdf URI. When enabled and specified in the protocol exchange, the IdP must follow GSA profile rules when performing the OpenID SSO protocol.
NIST authentication levels referenced by the http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf URI. When enabled, the IdP includes the NIST Level Of Assurance information in the response to the SP.
|
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:
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 WS-Federation, Liberty 1.x, SAML 1.0/1.1, SAML 2.0, and OpenID protocols.
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:
Propagating Authentication State to Oracle Access Manager in SP Mode
Propagating Authentication State to Oracle Single Sign-On in SP Mode
|
Note: Liberty 1.x support is deprecated. |
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.
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
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).
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.
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 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.
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).
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.
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 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
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:
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 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
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.
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.
This section explains installation requirements.
|
Note: Liberty 1.x support is deprecated. |
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.
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 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:
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 back-end identity and access management system, the AccessGate performance considerations apply, as do the Access Server sizing considerations outlined here:
http://www.oracle.com/technology/products/id_mgmt/pdf/wp-oracle-idm-sizing-considerations.pdf
Place the transient data store in memory for improved performance.
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.
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)
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.
Take into account the presence of other servers in your production environment. Specifically, consider:
Tuning Oracle WebLogic Server and setting appropriate connection limits for Oracle Identity Federation. You can:
Tune Oracle WebLogic Server using typical configuration parameters such as memory used, number of processes, and so on. For details, see Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server.
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 Oracle Fusion Middleware Performance and Tuning Guide .
Tuning the Oracle HTTP Server, which is leveraged by Oracle Identity Federation.
|
See Also: The following provide tuning and performance guidelines:
|
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.
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.
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. 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.
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.
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 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. |
|
|
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.
|
 Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
