This chapter describes key deployment scenarios, including integration with identity and access management systems, Web servers, and back-end data stores. It contains these topics:
Oracle Identity Federation operates in a heterogeneous environment and is interoperable with a wide variety of platforms and applications. It supports multiple options for data stores and authentication providers.
To resolve deployment issues and questions, refer to Chapter 2, "Planning Oracle Identity Federation Deployment" which provides extensive background information to help you plan your deployment:
Section 2.1, "Architecture Options" provides details about supported protocols and profiles, and what to consider when evaluating deployment options.
Section 2.6, "Sizing Guidelines" explains performance factors and provides topology recommendations.
Section 2.7, "Implementation Checklist"provides a deployment checklist.
The next section describes different deployment scenarios and provides step-by-step instructions for configuring Oracle Identity Federation to work with key components of the federation environment.
This section describes the steps needed to implement common Oracle Identity Federation deployment scenarios. It contains these sections:
Deploying Oracle Identity Federation with Oracle HTTP Server
Deploying Oracle Identity Federation with Oracle Single Sign-On
Deploying Oracle Identity Federation with Oracle Access Manager 11g
Deploying Oracle Identity Federation with Oracle Access Manager 10g
Oracle Identity Federation/SP Authenticating to Oracle Access Manager
Deploying Oracle Identity Federation with Oracle Directory Server Enterprise Edition
HTTP Servers are deployed in the Web tier.
Most Identity Management components can function without the Web tier, but for most enterprise deployments, the Web tier is desirable. To support enterprise level single sign-on using products such as Oracle Single Sign-On and Oracle Access Manager, the Web tier is required.
This section describes the steps needed to install and deploy Oracle Identity Federation so that it is integrated with Oracle HTTP Server (OHS).
Note:
When Oracle HTTP Server is installed, only the HTTP protocol is enabled. To enable SSL between Oracle HTTP Server and the managed server running Oracle Identity Federation, you must configure HTTPS post-install.
For details, refer to Oracle Fusion Middleware Administrator's Guide.
When installing the IdM suite, select Oracle HTTP Server in the Select Components screen. This will install Oracle HTTP Server.
After installation, issue the following command-line instruction to create the instance:
$AS_INST/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME
where $AS_INST represents the application server instance home, and $OHS_NAME is the name of the new OHS component.
The commands to start, stop, and restart Oracle HTTP Server respectively are as follows:
$AS_INST/bin/opmnctl startproc process-type=OHS $AS_INST/bin/opmnctl stopproc process-type=OHS $AS_INST/bin/opmnctl restartproc process-type=OHS
where AS_INST represents the application server instance home.
Next, take these steps to link Oracle HTTP Server to the managed server where Oracle Identity Federation is running:
Open $AS_INST/config/OHS/$OHS_NAME/moduleconf/oif.conf
where $AS_INST represents the application server instance home.
If Oracle Identity Management was installed in stand-alone mode, uncomment and set the WebLogicHost and WebLogicPort variables to reference the WebLogic managed server where Oracle Identity Federation is running (for example myhost.us.mycorp.com and 7499).
If the Oracle Identity Management is installed in clustered mode, uncomment and set the WebLogicCluster variable to reference the Oracle WebLogic Server managed servers where Oracle Identity Federation is running (for example myhost1.us.mycorp.com:7499, myhost2.us.mycorp.com:7499).
Save the file and exit.
Restart Oracle HTTP Server.
Next, take these steps to update the Oracle Identity Federation configuration:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Server Properties.
Change the hostname to reflect the hostname configured in OHS, if they are different.
Change the Port/SSL Enabled and SOAP Port/SSL Enabled information to reflect the OHS configuration.
Save the changes.
Since the Oracle Identity Federation metadata has changed, redistribute the metadata to any remote partners to notify them of the changes.
This section describes the steps needed to install and deploy Oracle Identity Federation so that it is integrated with Oracle Single Sign-On.
Deployed in this manner, Oracle Identity Federation can leverage the authentication capabilities offered by Oracle Single Sign-On when local user authentication is required. Oracle Identity Federation can:
integrate with OHS and Oracle Single Sign-On to serve as the authentication engine
integrate with Oracle Single Sign-On to serve as the SP integration Module.
Briefly, the steps to achieve this deployment are:
Configure Oracle Identity Federation to use Oracle Single Sign-On as the Authentication Engine
Configure Oracle Identity Federation for Oracle Single Sign-On SP Integration
Detailed instructions for these steps follow.
Note:
Oracle Identity Federation does not support the ability to force re-challenging the user for credentials when integrated with Oracle Single Sign-On, so that Oracle Identity Federation cannot support use cases where re-authentication must be forced.
For example, if an SP sends an AuthnRequest with ForceAuthn="true" to an Oracle Identity Federation IdP, and Oracle Identity Federation is integrated with Oracle Single Sign-On, the ForceAuthn flag is ignored.
To configure OHS, follow the instructions in Section 3.2.1, "Deploying Oracle Identity Federation with Oracle HTTP Server".
This integration is necessary to deploy Oracle Identity Federation with Oracle Single Sign-On.
Start by registering the mod_osso module in 11g Release 1 (11.1.1) OHS with the 10g Oracle Single Sign-On server as a partner application.
For details on this procedure, refer to Configuring and Administering Partner Applications in the Oracle Application Server Single Sign-On Administrator's Guide for 10g.
You need to run ssoreg from the Oracle Single Sign-On server to generate an osso.conf file and manually copy it to the partner application (AS_INST of the Oracle Identity Federation instance).
Here is an example for registering a remote partner application on an Oracle Single Sign-On server:
$ORACLE_HOME/sso/bin/ssoreg.sh -site_name oif.server.com:7499 -config_mod_osso TRUE -mod_osso_url http://oif.server.com:7499 -remote_midtier -config_file oif.server.com.osso.conf
Restart the OC4J_SECURITY instance of the Oracle Single Sign-On Server.
After you run this command, a file named oif.server.com.osso.conf is created in the directory where the command was invoked. Copy that file to $AS_INST/config/OHS/$OHS_NAME/.
The next step is to set up mod_osso.
Copy $AS_INST/config/OHS/$OHS_NAME/disabled/mod_osso.conf to $AS_INST/config/OHS/$OHS_NAME/moduleconf. All files in the moduleconf directory are read when OHS is started.
Open the $AS_INST/config/OHS/$OHS_NAME/moduleconf/mod_osso.conf file. Set the OssoConfigFile directive to reference the Oracle Single Sign-On configuration file that was created and then copied to the OHS config directory:
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/ ${COMPONENT_NAME}/oif.server.com.osso.conf
Add the /fed/user/authnosso URL to be protected by Oracle SSO Server, through the Location element.
Then the mod_osso.conf example would look like this:
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/
${COMPONENT_NAME}/oif.server.com.osso.conf
<Location /fed/user/authnosso>
require valid-user
AuthType Osso
</Location>
</IfModule>
Note:
If SSL is not enabled, you must add the OssoSecureCookies directive and set it to off; otherwise mod_osso will set the cookie as secure and instruct the browser to only send the cookie over HTTPS.
For details, see Secure Transmission of mod_osso Cookies in the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.
The mod_osso.conf file should look like this:
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoConfigFile ${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_NAME}/oif.server.com.osso.conf
</IfModule>
#
#
# To have short hostnames redirected to fully qualified
# hostnames for clients that need authentication via
# mod_osso to be able to enter short hostnames into their
# browsers use a mod_rewrite configuration such as the following.
#
# e.g
#RewriteEngine On
#RewriteCond %{HTTP_HOST} !www.example.com
#RewriteRule ^.*$ http://%{SERVER_NAME}%{REQUEST_URI} [R]
#where www.example.com is the fully qualified domain name.
Restart OHS for the configuration changes on mod_osso and mod_wl to take effect.
In this task you configure the server to use the Oracle Single Sign-On authentication engine. For more information, see Section 2.3.1, "Engines in Oracle Identity Federation".
Start with these steps to enable the Oracle Single Sign-On authentication engine:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Engines, then Oracle SSO.
Enable the engine.
Save the changes.
If Oracle Single Sign-On is only integrated as an authentication engine for Oracle Identity Federation, you will need to set up the Oracle Single Sign-On server to configure it for logout, and configure the Oracle Identity Federation server to configure it for logout.
To set up Oracle Single Sign-On:
Open $ORACLE_HOME/sso/conf/policy.properties.
Uncomment SASSOLogoutUrl.
Set the Oracle Identity Federation hostname/port information:
SASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/authnsloosso
Save the changes and exit.
Restart the OC4J_SECURITY instance.
To set up Oracle Identity Federation:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Engines, then Oracle SSO.
Enable logout.
Enter the Oracle Single Sign-On Server Logout URL:
http://osso-hostname:osso-port/sso/logout
Save the changes.
This task involves enabling Oracle Single Sign-On as a service provider integration module, and if needed, disable logout for the Oracle Single Sign-On authentication engine.
First, take these steps to enable the Oracle Single Sign-On SP Module in Oracle Identity Federation:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider Integration Modules, then Oracle SSO.
Enable the SP Module.
Select the authentication mechanism that will be used to locally authenticate users if federated identities are used during Federation SSO and if a federation record needs to be created during the SSO operation.
Enter the username attribute that Oracle Identity Federation needs to provide to Oracle SSO. Default is uid.
Enter the Oracle Single Sign-On server login URL:
http://osso-hostname:osso-port/sso/auth
Enter the Oracle Single Sign-On server logout URL:
http://osso-hostname:osso-port/sso/logout
Check Logout Enabled.
Click Regenerate OSSO Secret to create an encryption key that will be saved in a file and provided to Oracle Single Sign-On. Save the keystore locally.
Save the changes.
If Oracle Single Sign-On is integrated as an authentication engine for Oracle Identity Federation and an SP integration module, then the Oracle Single Sign-On authentication engine logout must be disabled, as the SP integration module is managing the logout. To disable the logout for Oracle Single Sign-On authentication engine in Oracle Identity Federation:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Authentication Engines, then Oracle SSO.
Disable logout.
Save the changes.
This part of the setup requires setup on the Oracle Single Sign-On server, and partner configuration.
Note:
A partner application is an Oracle Application Server-based application or a non-Oracle application that delegates the authentication function to the Oracle Single Sign-On server. A partner application is responsible for determining whether a user authenticated by Oracle Single Sign-On is authorized to use the application.
To set up Oracle Single Sign-On:
Copy the keystore file previously generated to the $ORACLE_HOME/sso/conf location and save it as a keystore.
Open $ORACLE_HOME/sso/conf/policy.properties.
Uncomment SASSOAuthnUrl, SASSOLogoutUrl, SASSOAuthLevel and MediumHighSecurity_AuthPlugin.
Set the Oracle Identity Federation hostname/port information for: SASSOAuthnUrl= http\://oif-hostname\:oif-port/fed/user/sposso
Set the Oracle Identity Federation hostname/port information for: SASSOLogoutUrl = http\://oif-hostname\:oif-port/fed/user/spsloosso
Set the authentication level for the Oracle Identity Federation plugin: SASSOAuthLevel = MediumHighSecurity
Set the MediumHighSecurity_AuthPlugin, which will define the Oracle Identity Federation plug-in: MediumHighSecurity_AuthPlugin = oracle.security.sso.server.auth.SASSOAuth
Save the changes and exit.
Restart the OC4J_SECURITY instance.
To configure a partner to use Oracle Identity Federation as the authentication plug-in:
Open $ORACLE_HOME/sso/conf/policy.properties.
Add the partner application to be protected by the authentication level mapped to the Oracle Identity Federation plug-in. For example:
content.example.com\:8888 = MediumHighSecurity
Save the changes and exit.
Restart the OC4J_SECURITY instance.
Take these steps to test your federated single sign-on setup:
Use a web browser to access a protected resource. When prompted by the identity provider, log in using credentials in the IdP's domain. When prompted by the service provider, log in using credentials in the SP's domain. You should now be redirected to the protected resource.
For details about protecting partner applications and resources see Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.
Log out, and then try to access the protected resource again. You should be prompted for login only by the identity provider.
You can integrate identity federation with the Oracle Access Access Manager server (OAM Server) 11g Release 1.
For integration details, see:
This section describes the steps needed to install and deploy Oracle Identity Federation so that it is integrated with Oracle Access Manager 10g. Integration enables Oracle Identity Federation to interact with Oracle Access Manager to create an authenticated user session. The steps illustrate a deployment scenario consisting of two nodes.
The section is broken out into separate instructions for the different component installation and deployment tasks:
Note:
Oracle Access Manager policy objects created by Oracle Identity Federation should not be changed from within Oracle Access Manager Policy/Access Manager administration interface; these objects can be identified by the description "Created by OIF. Do not modify". Modifying such objects from Oracle Access Manager can lead to synchronization issues; always update these policy objects from Fusion Middleware Control.
Note:
Oracle Identity Federation does not support the ability to force re-challenging the user for credentials when integrated with the Oracle Access Manager 10g authentication engine, so that Oracle Identity Federation cannot support use cases where re-authentication must be forced.
For example, if an SP sends an AuthnRequest with ForceAuthn="true" to an Oracle Identity Federation IdP, and Oracle Identity Federation is integrated with Oracle Access Manager, the ForceAuthn flag is ignored.
The steps to create and manage your 11g Release 1 (11.1.1) OHS component instance are:
Create the OHS instance.
Link OHS instance to the Oracle WebLogic Server managed server where Oracle Identity Federation is running.
Update the Oracle Identity Federation configuration.
Manage the OHS instance.
See Also:
Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.
Create the Oracle HTTP Server Instance
Note:
$OHS_NAME refers to the name of the OHS component.
Execute this command to create the instance:
$AS_ISNT/bin/opmnctl createcomponent -componentType OHS -componentName $OHS_NAME
Link Oracle HTTP Server Instance to the Managed Server
To enable OHS to connect to the managed server where Oracle Identity Federation runs, take these steps:
Open $AS_ISNT/config/OHS/$OHS_NAME/moduleconf/oif.conf.
If the Idm installation is in standalone mode, uncomment and set the WebLogicHost and WebLogicPort variables to reference the WLS managed server where Oracle Identity Federation is running (for example myhost.mycorp.com and 7499).
If the Idm installation is in clustered mode, uncomment and set the WebLogicCluster variable to reference the WLS managed servers where Oracle Identity Federation is running (for example myhost1.mycorp.com:7499, myhost2.mycorp.com:7499).
Save the changes, exit, and restart OHS.
See Also:
”Section 3.2.1.2, "Manage the Oracle HTTP Server Instance" for restart instructions.
See Also:
Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.
Update the OHS Configuration in Oracle Identity Federation
To enable the Oracle Identity Federation server to recognize OHS, take these steps:
Locate the Oracle Identity Federation instance in Fusion Middleware Control.
Navigate to Administration, then Server Properties.
Change the hostname to reflect the hostname configured in OHS, if different.
Change the Port/SSL Enabled and SOAP Port/SSL Enabled information to reflect the OHS configuration.
Save the changes.
Since the Oracle Identity Federation metadata will have changed, redistribute the metadata to any remote partners to notify them of the changes.
Manage the Oracle HTTP Server Instance
To start OHS:
$AS_ISNT/bin/opmnctl startproc process-type=OHS
where $AS_INST is the application server instance home.
To stop OHS:
$AS_ISNT/bin/opmnctl stopproc process-type=OHS
To restart OHS:
$AS_ISNT/bin/opmnctl restartproc process-type=OHS
See Also:
Section 2.3, "Authentication Engines" to review the features and benefits of authentication engines.
Oracle Access Manager as an authentication engine protects the /fed/user/authnoam URL.
The steps to configure this feature are:
Verify requirements and update default OHS configuration
Integrate OHS with Oracle Access Manager
Configure Oracle Access Manager
Configure Oracle Identity Federation
Take these steps to verify component versions:
Verify that the Oracle Access Manager server is at Version 10.1.4.3.
Verify that the Oracle Access Manager WebGate is installed for 11gR1 OHS (2.2).
Take these steps at the OHS:
Edit the $AS_ISNT/config/OHS/$OHS_NAME/httpd.conf file.
Uncomment the User and Group directives in the httpd.conf file, or add it.
Replace the default values of nobody with the user and users group that installed OHS 11g Release 1 (11.1.1), or add the user and users group if User and Group directives were missing.
For example:
User oracle Group dba
Integrate Oracle HTTP Server with Oracle Access Manager
Use the Oracle Access Manager console to create a new AccessGate and associate it with an Access Server instance.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.
See Also:
Oracle Access Manager Installation Guide 10g for details about installing WebGate.
On the machine where OHS is installed, install WebGate using these steps:
Launch the Install Wizard to install WebGate for Oracle HTTP Server11g
Enter the AccessGate details and the Access Server connection information.
Enter the location of the Oracle HTTP Server httpd.conf file (it should be $AS_ISNT/config/OHS/$OHS_NAME/httpd.conf) in order for WebGate to integrate with Oracle HTTP Server.
Configure Oracle Access Manager
Oracle Access Manager needs to protect an Oracle Identity Federation resource through WebGate. Since the WebGate is already installed, Oracle Access Manager needs only to have a policy that will protect the Oracle Identity Federation server in order to use Oracle Access Manager as an authentication engine. Once Oracle Access Manager authenticates, it will need to provide to Oracle Identity Federation the user identifier as an HTTP header.
Take these steps to configure Oracle Access Manager:
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.
Go to the Oracle Access Manager console and navigate to the Policy Manager.
Protect the /fed/user/authnoam resource in a domain with an authentication scheme and an authorization rule.
In the Authorization Rule, go to the Actions tab, click Modify and in the Authorization Success section, add a Return property that will be an HTTP header with a value set to the user ID. (For example, set Type to headervar, set Name to userid, set Return Attribute to uid.)
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g
Configure Oracle Identity Federation
Take these steps:
Locate the Oracle Identity Federation instance in Fusion Middleware Control.
Navigate to Administration, then Authentication Engines, then Oracle Access Manager.
Enable the Engine.
Enter the HTTP header containing the User ID.
Perform these logout configuration steps if Oracle Identity Federation and Oracle Access Manager are integrated only through the authentication engine framework. Otherwise, disable logout for Oracle Access Manager authentication Engine here and see Section 3.2.4.3, "Integrate Oracle Access Manager as an SP Integration Module" to configure logout operation.
Check the Logout Enabled box if logout needs to be enabled.
Check the Clear Cookie box if resetting the Oracle Access Manager cookie is enough for Oracle Identity Federation to log the user out of the Oracle Access Manager domain.
Check Redirect to Logout URL and fill in the URL if Oracle Identity Federation needs to redirect the user to a specific URL for Oracle Access Manager logout. See the note below for more information.
Save the changes.
Note:
When the user needs to be redirected to an Oracle Access Manager URL for logout (in case Oracle Access Manager needs to perform extra operations), you need to configure Oracle Identity Federation by checking the Redirect to Logout URL box, and entering the URL to which the user is redirected. When Oracle Identity Federation redirects the user to that URL, it will append a return URL as a query parameter; this is the Oracle Identity Federation URL to which the user is redirected after performing the extra Oracle Access Manager operations.
The query parameter to be appended to the Oracle Access Manager logout URL is referenced by returnurl.
Note:
The fix for Oracle Access Manager bug 5736326 is required when protecting the /fed/user/authnoam URL with HTTP Basic Authentication.
Using an Alternate Return Attribute for the HTTP Header
When Oracle Identity Federation is integrated with Oracle Access Manager for authentication, WebGate is protecting the /fed/user/authnoam URL, and Oracle Access Manager is configured to pass the user identifier as an HTTP header to Oracle Identity Federation, the policy protecting the /fed/user/authnoam URL contains an authorization rule with an action that adds an HTTP header with a return attribute referencing the user ID from the LDAP user record. This return attribute is the same as the Unique User ID set in Fusion Middleware Control when you navigate to the Oracle Identity Federation instance, under Administration, then Data Stores, then User Data Store section.
Due to a bug, orclguid cannot be used as the return attribute for the HTTP header containing the user identifier. As a workaround, the unique user identifier must be changed to another attribute. To perform the change:
change the return attribute in the Oracle Access Manager console to the new attribute (uid for example).
in Fusion Middleware Control navigate to Oracle Identity Federation Administration, then Data Stores, then User Data Store, and change the Unique User ID to the new attribute (uid for example).
if other authentication engines were used, check that their Unique User ID attributes is correctly updated.
if Oracle Identity Federation was integrated with Oracle Access Manager through the Oracle Access Manager SP Integration Module, update the integration: after performing the above changes, navigate to the Oracle Identity Federation instance in Fusion Middleware Control, then Administration, then SP Integration Modules, then OAM SP Engine, enter the Oracle Access Manager administrator credentials, select the created authentication schemes to be updated, and click "Configure Oracle Access Manager"; this updates the mapping rules in Oracle Access Manager to reflect the new attribute.
This task enables the SP integration module to interact with Oracle Access Manager.
The basic steps are:
Verify requirements
Install Oracle Access Server SDK
Integrate Oracle Access Manager with Oracle Access Server SDK
Update the Oracle WebLogic Server Classpath
Configure Oracle Identity Federation
Integrate Oracle Identity Federation with Oracle Access Manager
Protect an Oracle Access Manager Resource with Oracle Identity Federation
Take these steps:
Ensure Access Server SDK 10g is installed.
In a high availability (HA) environment, the Access Server SDK needs to be installed on different machines, and integrated as different AccessGates with Oracle Access Manager.
Note:
When deploying in an HA environment, be sure to read and complete the instructions in the section High Availability Considerations for Integration with Oracle Access Manager in the Oracle Fusion Middleware High Availability Guide.
Be sure to follow the directions regarding the directory where the Access Server SDK is installed, and restart all managed servers.
Install Oracle Access Server SDK
Configure Oracle Identity Federation to reference the directory where the SDK is installed.
If the SDK is installed in the Domain Home directory, you can reference the SDK folder relative to the Domain Home folder; otherwise, Oracle Identity Federation needs to reference the SDK folder using an absolute path.
To use Oracle Identity Federation in an HA environment, it is preferable to install the Access Server SDK under the Domain Home folder, using the same directory name relative path on the different machines where Oracle Identity Federation is installed. This way, the different Oracle Identity Federation instances share the same configuration; specifically, the directory where the Access Server SDK is installed has the same value for all the Oracle Identity Federation instances.
Integrate Oracle Access Manager with Oracle Access Server SDK
This task enables a new AccessGate to be associated with an Access Server instance.
On the Oracle Access Manager console, create the new AccessGate with Access Management Service enabled, and associate it with the Access Server instance.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.
Integrate the Access Server SDK by invoking the configureAccessGate script:
$ACCESS_SERVER_SDK/oblix/tools/configureAccessGate -i $ACCESS_SERVER_SDK -t AccessGate -w $ACCESS_GATE_ID -m open -h $ACCESS_SERVER_HOST -p $ACCESS_SERVER_PORT
replacing:
$ACCESS_SERVER_SDK by the absolute path of the Access Server SDK directory
$ACCESS_GATE_ID by the identifier for this Access Gate
$ACCESS_SERVER_HOST by the hostname of machine where the Access Server is installed
$ACCESS_SERVER_PORT by the port of the Access Server.
Update the Oracle WebLogic Server Environment
The managed server where Oracle Identity Federation is running needs to be able to access the JAR file and the shared libraries required for Oracle Access Manager integration.
See Also:
Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.
To update the environment:
Stop managed server.
See Also:
Starting and Stopping WebLogic Servers in the Oracle Fusion Middleware Administrator's Guide.
Copy the jobaccess.jar file from the $ASDK_DIR/oblix/lib folder to the $DOMAIN/lib folder.
The next step depends on the version of Oracle Access Manager you are running.
If you are at Oracle Access Manager version 10.1.4.3 or later and want to start the managed server from the WebLogic administration console, follow these steps:
Open the WebLogic administration console.
Navigate to Servers, then Managed Server, then Configuration, then Server Start.
In the text box for Arguments, append -Djava.library.path to include ASDK_DIR/oblix/lib.
Save the changes.
Start the managed server from the console.
See Also:
Understanding Key Oracle Fusion Middleware Concepts in the Oracle Fusion Middleware Administrator's Guide.
If you are at Oracle Access Manager version 10.1.4.2 or earlier, or if you are at Oracle Access Manager version 10.1.4.3 and wish to start managed server from the command line:
Copy the jobaccess.jar file from the $ASDK_DIR/oblix/lib folder to the $DOMAIN/lib folder.
Stop managed server.
On Linux, open the file $DOMAIN/bin/startManagedWebLogic.sh:
Add the following lines:
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:accessSDK installdir/oblix/lib
export LD_LIBRARY_PATH
If the Oracle Access Manager version is 10.1.4.2 or earlier, add the following two lines as well:
LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL
On Windows, open the file $DOMAIN/bin/startManagedWebLogic.cmd:
Add the following line:
set PATH=%PATH%;AccessSDK_InstallDir/oblix/lib
Start managed server from the command line (not the administration console).
Configure Oracle Identity Federation
Take these steps:
Locate the Oracle Identity Federation instance in Fusion Middleware Control.
Navigate to Administration, then Service Provider Integration Modules, then Oracle Access Manager.
Enable the SP module.
Select the authentication mechanism to use when processing a SAML assertion (required in some cases when a local federation record needs to be created for the user).
Enter the directory where the Access Server SDK is installed. If the SDK is installed under the $DOMAIN_HOME directory, then the path to the folder can be relative to $DOMAIN_HOME; otherwise the path must be absolute.
Enter the default authentication scheme that Oracle Identity Federation should use when creating user sessions in Oracle Identity Federation.
Enter the cookie domain that Oracle Identity Federation will set when creating the Oracle Access Manager cookie.
Oracle Identity Federation can set the Oracle Access Manager cookie as either a persistent cookie or a session cookie. For a persistent cookie, enter the time in minutes during which the cookie will be valid; for a session cookie, enter 0.
Check whether the cookie should be marked as secure: in this case, the browser will send the cookie over an HTTPS connection.
Check the Logout Enabled box if logout needs to be enabled (recommended).
Check the Clear Cookie box if resetting the Oracle Access Manager cookie is enough for Oracle Identity Federation to log the user out of the Oracle Access Manager domain.
Check Redirect to Logout URL and fill in the URL if Oracle Identity Federation needs to redirect the user to a specific URL for Oracle Access Manager logout.
Note:
When the user needs to be redirected to an Oracle Access Manager URL for logout (in case Oracle Access Manager needs to perform extra operations), you need to configure Oracle Identity Federation by checking the Redirect to Logout URL box, and entering the URL to which the user is redirected. When Oracle Identity Federation redirects the user to that URL, it will append a return URL as a query parameter; this is the Oracle Identity Federation URL to which the user is redirected after performing the extra Oracle Access Manager operations.
The query parameter to be appended to the Oracle Access Manager logout URL is referenced by returnurl.
Save your changes.
Note:
The cookie domain must be set on the Webgate for the protected resource. An example of a cookie domain is:
.us.example.com
You use Fusion Middleware Control to configure the user data store that Oracle Identity Federation uses when creating policy objects in the Oracle Access Manager Policy Server.
If you change the user data store through Fusion Middleware Control:
redo the Oracle Identity Federation/Oracle Access Manager integration
update the existing authentication schemes that were created by Oracle Identity Federation in the Oracle Access Manager Policy Server.
Integrate Oracle Identity Federation with Oracle Access Manager
After processing an incoming SSO assertion and identifying the user, Oracle Identity Federation will create an Oracle Access Manager session for that user in the Oracle Access Manager domain. To do so, Oracle Identity Federation will:
Use a policy domain created by Oracle Identity Federation at configuration time.
Map the Oracle Identity Federation authentication mechanism, representing the authentication method used by the IdP to challenge the user, to an Oracle Access Manager authentication scheme that was created by Oracle Identity Federation at configuration time. If the mapped Oracle Access Manager authentication scheme does not exist, then Oracle Identity Federation will use the default authentication scheme entered in the Oracle Identity Federation configuration section
Interact with Oracle Access Manager to create the user session, by specifying the policy domain and the authentication scheme for that session
The policy domain name that you enter for Oracle Identity Federation cannot reference an existing policy domain that was not created by Oracle Identity Federation. It must be created by Oracle Identity Federation.
Set the Oracle Access Manager cookie in the user's browser
For proper integration, Oracle Identity Federation needs to create policy objects and authentication schemes in Oracle Access Manager. Perform the following operations:
Note:
This task assumes you have the appropriate administrator credentials for Oracle Access Manager. Ensure that the Oracle Access Manager Master Administrators account is used to create the policy objects.
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g
See Also:
Section 5.16.3, "SP Integration Module - Oracle Access Manager 10g" for screen details.
Locate the Oracle Identity Federation instance in Fusion Middleware Control.
Navigate to Administration, then Service Provider Integration Modules, then Oracle Access Manager.
Expand the Oracle Access Manager Properties section.
Enter the Oracle Access Manager credentials to configure Oracle Access Manager.
Note:
Credentials will only be used to connect to the Oracle Access Manager Server for configuration when you click the Configure Oracle Access Manager button; these credentials are not stored in any Oracle Identity Federation configuration file.
Enter the Host ID that Oracle Identity Federation must use when configuring the policy domain. Define the Host ID in the Oracle Access Manager server. The Host ID must contain the hostname:port information that the Oracle Identity Federation server is configured to use, and its variations.
Note:
This is a required parameter.
Enter the default authorization rule that will be used when creating the policy domain.
The available Oracle Identity Federation authentication mechanisms are listed in the table; for each, the table lists the mapped authentication scheme name and its authentication scheme level. These mappings are stored in Oracle Identity Federation only by default, and you need to select the mechanisms and schemes to be created, updated, or deleted in Oracle Access Manager.
When you select a scheme to create, and click Configure Oracle Access Manager, the scheme is created with the specified name and level, and mapped to the corresponding authentication mechanism in the Oracle Identity Federation configuration. You must select one of the created schemes as the default Oracle Access Manager authentication scheme used by Oracle Identity Federation. By default this value is password-protected by Oracle Identity Federation, so if nothing is selected as default, the password-protected authentication scheme must be selected for create. If you select a scheme to delete, likewise, the scheme is deleted from Oracle Access Manager. If you select a scheme for update, the default Oracle Access Manager authentication scheme used by Oracle Identity Federation, and its name, are updated in Oracle Access Manager.
Note:
In order that the server can update/delete the authentication scheme, it must not be in use by any domains.
Click Configure Oracle Access Manager.
Protect an Oracle Access Manager Resource with Oracle Identity Federation
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for 10g.
After integrating Oracle Identity Federation with Oracle Access Manager and creating authentication schemes, you can now protect resources using the schemes you have created. Protecting a resource with a specific scheme has the following effect:
When a non-authenticated user (or an authenticated user with authentication level lower than that of the scheme) tries to access a resource protected by an Oracle Identity Federation authentication scheme, the Oracle Access Manager server redirects the user to Oracle Identity Federation for Federation SSO.
Oracle Access Manager provides Oracle Identity Federation the resource being requested and the Oracle Identity Federation authentication scheme name to be used.
Oracle Identity Federation maps that authentication scheme to an authentication mechanism, and then to a SAML/WS-Fed authentication method.
Oracle Identity Federation starts the Federation SSO flow by sending the user to an identity provider and by specifying the authentication method to use in challenging the user for authentication.
The IdP will challenge the user, create an assertion and send the user back to Oracle Identity Federation with the assertion.
Oracle Identity Federation processes the assertion, extracting from it the method used to authenticate the user and map it to an authentication mechanism.
After successful processing, Oracle Identity Federation maps the authentication mechanism to an authentication scheme and creates an Oracle Access Manager session for the user.
Oracle Identity Federation redirects the user to the requested resource.
Finally Oracle Access Manager grants access to the resource for the authenticated user.
You can configure Oracle Identity Federation, when acting as service provider, to authenticate itself to the Oracle Access Manager server when creating an Oracle Access Manager user session.
Topics in this section include:
This authentication operation occurs when Oracle Identity Federation uses an Oracle Access Manager federation authentication scheme, through the AccessGate installed on the machine hosting Oracle Identity Federation, to create a user session.
The operation ensures that the module invoking the scheme is indeed the Oracle Identity Federation server and that no other process is trying to use the scheme.
The deployment and run-time flow are as follows:
Using Fusion Middleware Control, the Oracle Identity Federation administrator creates/updates the existing Oracle Access Manager federation schemes to add two new plugins
Using Fusion Middleware Control, the Oracle Identity Federation administrator provides the necessary credentials to OIF
At runtime, Oracle Identity Federation passes the credentials along with the data used to create the Oracle Access Manager user session
The Oracle Access Manager server validates the Oracle Identity Federation credentials against the LDAP user repository
After the Oracle Identity Federation credentials are validated, an Oracle Access Manager user session is created
The administrator can customize the LDAP account used to validate the Oracle Identity Federation credentials to select:
the location of the entry (that is, location different from the user's branch)
the object class of the entry
Servers Authorized to Invoke Authentication
For security reasons, the Oracle Identity Federation username can be set in the credential_mapping plugin of the federation scheme. This ensures that only the user corresponding to that account can be used when invoking this scheme.
This feature is optional, but enabling it ensures that only authorized Oracle Identity Federation servers invoke the federation authentication schemes.
In this scenario:
Oracle Identity Federation is already deployed and integrated with Oracle Access Manager
Oracle Identity Federation is not configured for authentication to Oracle Access Manager
no federation schemes created in the Access server are configured for Oracle Identity Federation authentication to Oracle Access Manager
The configuration involves:
creating an account in the LDAP directory to use for Oracle Identity Federation authentication
setting Oracle Identity Federation account information to enable authentication using Fusion Middleware Control
updating all existing federation schemes to define the new Oracle Access Manager plugins using Fusion Middleware Control
updating all existing federation schemes to define new authentication flows for the new plugins using the Oracle Access Manager console
So that Oracle Identity Federation can authenticate to Oracle Access Manager when using a federation scheme, the LDAP directory must contain an entry to use in validating the Oracle Identity Federation credentials. If no such entry exists, create one that is both searchable based on an identifier and has a password attribute. You use Fusion Middleware Control to set:
the identifier
passwords
the base DN of the entry
the entry's object class
the attribute to contain the identifier
You can choose:
a location for the entry different from the branch where all user records are located
an object class different from the user record type
Set Up Oracle Identity Federation Account Information
To configure Oracle Identity Federation to present credentials when invoking a federation scheme, take these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Check the box to enable Oracle Identity Federation authentication.
Enter the username and password of the account to use for Oracle Identity Federation authentication.
Enter the Base DN referencing the location where the Oracle Identity Federation account is located.
Enter the object class of the LDAP entry to use for Oracle Identity Federation authentication.
Enter the LDAP entry attribute that will contain the username and is searchable (for example, uid if it is defined in the LDAP entry).
Next update the existing federation schemes to include two new plugins used for the authentication operation. Take these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Select and click Update for all the federation schemes that were created in Oracle Access Manager.
Enter the Oracle Access Manager administrator credentials to enable administrative update operations to be performed on the Oracle Access Manager server.
Click Configure Oracle Access Manager.
This updates the schemes with two new plugins:
a credential_mapping plugin used to locate the Oracle Identity Federation account.
a validate_password plugin used to validate the password provided by Oracle Identity Federation against the one from the Oracle Identity Federation account.
Define New Authentication Flows
Due to Access Server limitations, you cannot use Fusion Middleware Control to create new authentication flows to uptake the new plugins created in the previous step; instead, you must use the Oracle Access Manager console to create those objects.
For each federation scheme you updated, perform these actions:
Log in to the Oracle Access Manager console as administrator.
Navigate to the Access System Console, then Access System Configuration, then Authentication Management.
Select the federation scheme you wish to update.
Click the Steps tab.
Click Add to add a new step.
Enter a name for the step in the "Step Name" field.
In the "Available Plugins" table, perform these steps in order:
Note:
The order is important.
Select the second credential_mapping plugin and click add.
Select the validate_password plugin and click add.
Select the first credential_mapping plugin and click add.
Click Save.
Click the Authentication Flow tab.
Click Modify.
Select the new step as the "Initiating Step".
Select Stop for "On Success Next Step".
Select Stop for "On Failure Next Step".
Click Save.
Click the Steps tab.
Select the old step. Click Delete.
This configuration supports the following scenario:
Oracle Identity Federation is already deployed and integrated with Oracle Access Manager, or Oracle Identity Federation is deployed but not yet integrated with Oracle Access Manager.
Oracle Identity Federation is not configured for authentication to Oracle Access Manager.
No federation schemes have been created in Access server.
The tasks include:
creating the account in the LDAP directory used for Oracle Identity Federation authentication
setting information about the Oracle Identity Federation account, and any Oracle Identity Federation/Oracle Access Manager integration which might involve creating new authentication schemes, in Fusion Middleware Control.
creating new federation schemes using Fusion Middleware Control
So that Oracle Identity Federation can authenticate to Oracle Access Manager when using a federation scheme, the LDAP directory must contain an entry to use in validating the Oracle Identity Federation credentials. If no such entry exists, you must create one that is both searchable based on an identifier and has a password attribute. You use Fusion Middleware Control to set:
the identifier
passwords
the base DN of the entry
the entry's object class
the attribute to contain the identifier
You can choose:
a location for the entry different from the branch where all user records are located
an object class different from the user record type
Set Up Oracle Identity Federation Account Information
To configure Oracle Identity Federation to present credentials when invoking a federation scheme, take these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Enable Oracle Identity Federation authentication.
Enter the username and password of the account to use for Oracle Identity Federation authentication.
Enter the Base DN referencing the location where the Oracle Identity Federation account is located.
Enter the object class of the LDAP entry to use for Oracle Identity Federation authentication.
Enter the LDAP entry attribute that will contain the username and is searchable (for example, uid if it is defined in the LDAP entry).
Configure the rest of the fields for Oracle Access Manager as needed, and click Configure Oracle Access Manager to apply the changes.
Any federation schemes created subsequently will contain the necessary information to authenticate Oracle Identity Federation at runtime. No manual steps are needed in the Oracle Access Manager console to update the federation authentication schemes.
In this scenario:
Oracle Identity Federation is already deployed and integrated with Oracle Access Manager.
Oracle Identity Federation is configured for authentication to Oracle Access Manager.
Federation schemes exist and are configured to perform Oracle Identity Federation authentication at run-time.
Updating Oracle Identity Federation credentials may necessitate updates to the federation schemes:
if only the Oracle Identity Federation password is updated, federation schemes can remain unchanged
if information about the Oracle Identity Federation account other than password (object class, base DN, username, and so on) is updated, all federation schemes must be updated.
Update Oracle Identity Federation Password Only
If updating only the Oracle Identity Federation password, take these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Enter the password of the account to be used for Oracle Identity Federation authentication.
Click Configure Oracle Access Manager to apply the changes.
Update Other Data Besides Password
When updating other information besides the Oracle Identity Federation password, perform the following steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Update the username and/or password of the account to use for Oracle Identity Federation authentication, as needed.
Update the Base DN referencing the location where the Oracle Identity Federation account is located, as needed.
Update the object class of the LDAP entry to use for Oracle Identity Federation authentication, as needed.
Update the LDAP entry attribute that will contain the username and is searchable (for example, uid if it is defined in the LDAP entry), as needed.
Select and click Update for all the federation schemes that were created in Oracle Access Manager.
Enter the Oracle Access Manager administrator credentials to enable administrative update operations to be performed on the Oracle Access Manager server.
Click Configure Oracle Access Manager.
The federation schemes now contain updated information in the credential_mapping plugin for the Oracle Identity Federation authentication operation.
In this scenario:
Oracle Identity Federation is already deployed and integrated with Oracle Access Manager.
Oracle Identity Federation is configured for authentication to Oracle Access Manager.
Federation schemes exist and are configured to perform Oracle Identity Federation authentication at run-time.
The tasks involve:
updating the existing federation schemes to remove objects involved in Oracle Identity Federation authentication
disabling Oracle Identity Federation authentication with Fusion Middleware Control
Update Existing Federation Schemes
This procedure updates the federation schemes so that they no longer require Oracle Identity Federation authentication. If this is not done, the schemes would continue to expect credentials but Oracle Identity Federation would no longer be sending them.
For each of the federation scheme that was updated, take these steps:
Navigate to Access System Console, then Access System Configuration, then Authentication Management.
Select the federation scheme to update.
Select the Steps tab.
Click Add to add a new step.
Enter a name for the step in the "Step Name" field.
The next step depends on when Oracle Identity Federation authentication was enabled (before or after creation of this scheme).
If the order of the plugins is credential_mapping, then validate_password, then credential_mapping, select the last credential_mapping plugin and click add.
if the order of the plugins is credential_mapping, then credential_mapping, then validate_password, select the first credential_mapping plugin and click add.
Click Save.
Click the Authentication Flow tab.
Click Modify.
Select the new step as the "Initiating Step"
Select Stop for "On Success Next Step".
Select Stop for "On Failure Next Step".
Click Save.
Click the Steps tab.
Select the old step. Click Delete.
Click the Plugins tab.
Click Modify.
Select the validate_password plugin and the credential_mapping plugin with a plug-in parameter where the Oracle Identity Federation username is specified.
Click Delete, then Save.
After this action, the only remaining plugin is the credential_mapping plugin with a plugin parameter containing the string %OIFUSERID%.
Disable Oracle Identity Federation Authentication
Take these steps to disable authentication:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to SP Integration Modules, then Oracle Access Manager.
Disable Oracle Identity Federation authentication.
Click Configure Oracle Access Manager to apply the change.
After this action, Oracle Identity Federation no longer sends credentials for authentication when invoking a federation scheme.
To Re-enable Oracle Identity Federation Authentication
To re-enable the Oracle Identity Federation authentication to Oracle Access Manager after disabling it, follow the instructions in Section 3.2.5.2, "Enabling Authentication with Existing Federation Schemes".
This section describes how to integrate Oracle Directory Server Enterprise Edition (formerly Sun Java System Web Server) with Oracle Identity Federation to serve as a web proxy.
This section contains the following topics:
Configuring Oracle Identity Federation Without a Web Proxy Server
Configuring Oracle Identity Federation Behind a Web Proxy Server
Oracle Directory Server Enterprise Edition Sample Configuration Files
When using a proxy in front of Oracle Identity Federation, the host name and port number of the proxy server instance are used to access Oracle Identity Federation, and are set in the Oracle Identity Federation configuration.
Start by installing Oracle Identity Federation, and configure and integrate it with any back-ends (LDAP, RDBMS, Oracle Access Manager, and others) required by your deployment. This includes:
configuring Oracle Identity Federation for SSO SAML protocols
adding trusted providers to Oracle Identity Federation's Federations
integrating Oracle Identity Federation with back-ends
When configuring Oracle Identity Federation behind a Web Proxy server, the steps are similar to the ones performed in a non-Web Proxy server environment as described in Section 3.2.6.2, "Configuring Oracle Identity Federation Without a Web Proxy Server", except that:
The Web Proxy server will be configured to reference Oracle Identity Federation
The Oracle Identity Federation configuration will use the hostname and port information of the Web Proxy Server
Follow the standard procedures to configure Oracle Identity Federation as shown in Section 3.2.6.2, "Configuring Oracle Identity Federation Without a Web Proxy Server", with these modifications:
Change the configuration URLs to their respective proxy server URLs.
In Fusion Middleware Control, navigate to Administration, then Server Properties.
Collect the metadata using the proxy URLs, not actual URLs, then upload the metadata.
Navigate to Administration, then Security and Trust, and retrieve the metadata (the hostname/port information in the metadata will now use the new values). Distribute the metadata to the remote providers.
At the Access System console, create a host identifier in the format:
proxy-host:port
and change the challenge redirect of the authentication scheme to proxy-host:port.
See Also:
Section 5.2, "Configuring Server Properties" and Section 5.10, "Configuring Security and Trust"
See Also:
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service 10g for details about the Web-based user interface.
For details about configuring the Sun One proxy server for Oracle Identity Federation, see Guidelines for Modifying the obj.conf File in Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server.
Users will now access Oracle Identity Federation through the Web server proxy, and the IAM servers like Oracle Access Manager also need to be updated so that they reference the proxy instead of the local Oracle Identity Federation machine.
Go to any back end that references Oracle Identity Federation (such as Oracle Access Manager or Oracle Single Sign-On), and update their configuration to use the hostname/port values of the Web proxy server instead of the local machine where Oracle Identity Federation is installed.
The Web proxy server will need to forward the HTTP requests to the machine where Oracle Identity Federation is installed.
This section provides samples of the obj.conf and magnus.conf configuration files.
<Object name="default"> AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true" NameTrans fn="assign-name" from="/*" name="serverexample" NameTrans fn="ntrans-j2ee" name="j2ee" NameTrans fn=pfx2dir from=/mc-icons dir="/home/pfx/SunOne6.1/ns-icons" name="es-internal" NameTrans fn=document-root root="$docroot" PathCheck fn=unix-uri-clean PathCheck fn="check-acl" acl="default" PathCheck fn=find-pathinfo PathCheck fn=find-index index-names="index.html,home.html,index.jsp" ObjectType fn=type-by-extension ObjectType fn=force-type type=text/plain Service method=(GET|HEAD) type=magnus-internal/imagemap fn=imagemap Service method=(GET|HEAD) type=magnus-internal/directory fn=index-common Service method=(GET|HEAD|POST) type=*~magnus-internal/* fn=send-file Service method=TRACE fn=service-trace Error fn="error-j2ee" AddLog fn=flex-log name="access" </Object> <Object name="j2ee"> Service fn="service-j2ee" method="*" </Object> <Object name="cgi"> ObjectType fn=force-type type=magnus-internal/cgi Service fn=send-cgi user="$user" group="$group" chroot="$chroot" dir="$dir" nice="$nice" </Object> <Object name="es-internal"> PathCheck fn="check-acl" acl="es-internal" </Object> <Object name="send-compressed"> PathCheck fn="find-compressed" </Object> <Object name="compress-on-demand"> Output fn="insert-filter" filter="http-compression" </Object> # Execute these instructions for any resource with the assigned name # "server.example.com" <Object name="serverexample"> # Proxy the requested resource to the URL # "http://server.example.com:8080" Service fn="service-passthrough" servers="http://unit1.mycorp.co.in:1234" </Object>
# # The NetsiteRoot, ServerName, and ServerID directives are DEPRECATED. # They will not be supported in future releases of the Web Server. NetsiteRoot /home/pfx/SunOne6.1 ServerName calgary ServerID https-oif_idp_flagstaff # RqThrottle 128 DNS off Security off PidLog /home/pfx/SunOne6.1/https-oif_idp_flagstaff/logs/pid User pfx StackSize 131072 TempDir /tmp/https-oif_idp_flagstaff-65cd125c Init fn=flex-init access="$accesslog" format.access="%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] \"%Req->reqpb.clf-request%\" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-length%" Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/lib/libj2eeplugin.so" shlib_flags="(global|now)" Init fn="load-modules" shlib="/home/pfx/SunOne6.1/bin/https/passthrough/plugins/passthrough /libpassthrough.so"
Oracle Identity Federation provides a test SP engine for the purpose of Single Sign-On testing. The following sections describe how to use the test SP engine.:
Note:
The test SP engine must be disabled in a production environment.
Take these steps to enable/disable the test SP engine:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider Integration Modules.
In the Test SP tab, select/unselect Enable Engine.
To make the test SP engine the default SP engine, follow these steps:
Log in to Fusion Middleware Control and navigate to the Oracle Identity Federation instance.
Navigate to Administration, then Service Provider Integration Modules.
Select Default SP Integration Module to be Test SP (Note: The test SP engine must be enabled).
To use the test engine, you can initiate a single sign-on flow at the following URL:
HTTP://OIF-SP-HOST:OIF-SP-PORT/fed/user/testspsso
where:
HTTP is http for an open connection and https for a secure connection
OIF-SP-HOST is the hostname of the Oracle Identity Federation service provider server
OIF-SP-PORT is the http or https port number of the Oracle Identity Federation service provider server. Omit the entry for port 80 or https port 443.
When you click the Start SSO button, a request is sent to the Oracle Identity Federation service provider to start Single Sign-On (that is, an authentication request is sent to the identity provider) with the information provided on the page. You can specify the following parameters:
IdP Provider ID: This is the Provider ID or description of the identity provider to which to the service provider will send the authentication request.
Authn Request Binding: This specifies the binding the service provider will use to send the authentication request. Applies only to SAML 2.0 protocol
Force Authentication: If checked, the identity provider is forced to authenticate the user, instead of possibly relying on a previous authentication context. Applies only to SAML 2.0/WS-Fed protocols.
Is Passive: If checked, the identity provider must not interact with the user. Applies only to SAML 2.0 protocol.
Relay State: In this field, you can enter any string. This is either an identifier for the request or a return URL and is returned as a relay state after the Oracle Sign-On flow has been performed.
Use Default Configuration: If checked, Oracle Identity Federation will use the default configuration for the following properties:
Allow Federation Creation
SSO Response Binding
Name ID Format
Requested Authentication Mechanism
Authentication Mechanism Comparison
If not checked, the following applies:
Allow Federation Creation: If not checked, the identity provider must not create a federation for the user, if one does not exist. Applies only to SAML 2.0 protocol
SSO Response Binding: This specifies the binding that the service provider will request the identity provider to use when sending the response. Applies only to SAML protocols
Name ID Format: This specifies the Name ID format that the service provider will request the identity provider to use when locating or creating a federation for the user. Applies only to SAML 2.0 protocol.
Requested Authentication Mechanism: This specifies the local authentication mechanism that the service provider will use. The service provider will map this local mechanism to a protocol-specific method, and specify this method in its authentication request to the identity provider. (See Section 5.14.1, "About Authentication Mechanisms".) Applies only to SAML 2.0/WS-Fed protocols.
Authentication Mechanism Comparison: If using SAML 2.0, specifies the comparator that the identity provider will use when determining the authentication mechanism to use. Options are:
EXACT: the identity provider must use the requested authentication mechanism
MINIMUM: the identity provider must use a mechanism that is at least as strong as the requested authentication mechanism
BETTER: the identity provider must use a mechanism that is stronger than the requested authentication mechanism
MAXIMUM: the identity provider must use a mechanism that is as strong as possible without exceeding the strength of the requested mechanism
You can also use the test SP engine to test IdP-initiated Single Sign-On. In the service provider, simply enable the test SP engine and configure the default SP engine to be Test SP, and begin IdP-initiated SSO from the identity provider. The test SP engine will display the results of the Single Sign-On operation.
After Single Sign-On has been performed, the test SP engine displays the results of the operation, including:
SSO Authentication Result: whether the operation was successful.
User Identifier: the User ID of the user for which Single Sign-On was performed.
Authentication Instant: the instant at which the identity provider authenticated the user.
Session Expiration Instant: the instant at which the user session will become invalid.
Authentication Mechanism: the local mechanism used to authenticate the user.
SSO Primary Status Code: The primary status code in the assertion received from the identity provider.
SSO Secondary Status Code: The secondary status code in the assertion received from the identity provider.
SSO Status Message: The status message in the assertion received from the identity provider.
IdP Provider ID: The Provider ID of the identity provider that authenticated the user.
A list of the attributes from the assertion received from the identity provider, including:
orafed-providerid: The Provider ID of the identity provider that authenticated the user.
orafed-nameid-format: The format of the Name ID of the user federation.
orafed-nameid-value: The Name ID of the user federation.
orafed-assertionid: The ID of the assertion received from the identity provider.
Any user attributes included in the assertion received from the identity provider.
This section describes actions that the administrator must take following an upgrade of Oracle Identity Federation.
During an upgrade from release 10g to 11g, the upgrade assistant migrates the Oracle Identity Federation 10g Liberty/SAML2.0 signing key/certificate as the signing certificate of the Oracle Identity Federation 11g instance for use in SAML2.0/SAML1.x/WS-Fed operations.
If you used the Oracle Identity Federation 10g server to sign SAML 1.x/WS-Fed messages, you have two options:
Keep the SAML1.x/WS-Fed key/certificate as the Oracle Identity Federation 11g signing key/certificate for all protocols (SAML2.0/SAML1.x/WS-Fed).
To implement this, upload the 10g keystore as the 11g signing keystore. The 10g keystore can be found in the Oracle Identity Federation Administration Console by navigating to SAML1x/WSFed, then Signer; the 11g keystore is located in Fusion Middleware Control by navigating to the Oracle Identity Federation instance, in the Security and Trust section.
You must redistribute the SAML2.0 metadata to the remote partners after the change, so that the partners have the new signing certificate.
Keep the SAML 2.0 signing key/certificate as the signing key/certificate of the Oracle Identity Federation 11g server.
To implement this, you will need to provide the new signing certificate to all SAML 1.x/WS-Fed partners.