Adding Oracle Identity Federation to an Existing Fusion Applications Deployment Part 2


This is the second part of a two-part article. Click here to view Part 1.

This guide is meant for existing FA customers who have deployed FA without OIF and who now wish to add this security component to the deployment to provide federated SSO to FA. Customers who have not yet begun their deployment can and should follow the Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) for the FA Release that they are deploying. The content of this article was generated using an FA Release 5 (11.1.5) environment, and it applies to FA versions 11.1.3 through 11.1.6. For those who are performing this on FA version 11.1.3 or 11.1.4, the EDG for FA version 11.1.5 should be referenced for additional information on the OIF deployment.

This article assumes that the implementer is conversant with OIF version, and is capable of configuring the product in the role of a federation Service Provider for a SAML 2.0 SP-initiated POST profile with an enterprise Identity Provider that is enabled for SAML 2.0.

Finally, the steps below are for a deployment on Oracle Enterprise Linux, and the steps for other operating systems will differ slightly.

Main Article

Loopback Test

The loopback test utilizes the FA OIF instance as both IDP and SP, and this is a functional test that allows a confirmation that OIF is operating properly. Open a browser and go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):


Right-click on OIF( and go to Administration > Identity Provider:


Ensure Enable Identity Provider is checked. If not, check it and click Apply. Right-click on OIF( and go to Administration > Identity Provider:


Ensure Enable Service Provider is checked. If not, check it and click Apply. Access the IDP metadata by going to the following URL (substitute actual values to this example):


Save the data as idp_metadata.xml:


Access the SP metadata by going to the following URL (substitute actual values to this example):


Save the data as sp_metadata.xml:


Right-click on OIF( and go to Administration > Federations and click Add:


Click Browse:


Select idp_metadata.xml and click Open:


Ensure Enable Provider is checked, enter IDP for Loopback Test for Description and click OK:


Click Add:


Click Browse:


Select sp_metadata.xml and click Open:


Ensure Enable Provider is checked, enter SP for Loopback Test for Description and click OK:


Right-click on OIF( and go to Administration > Authentication Engines:


Change Default Authentication Engine to LDAP Directory and click Apply:



Create a Test Webpage for Federated SSO

Creating a webpage for federated SSO testing allows for validating the federation configuration without affecting FA. Open a terminal window and navigate to the htdocs directory for the IDM WebTier, e.g., /u01/app/oracle/admin/web1/config/OHS/ohs1/htdocs. Create a directory named ‘oiftest’ and copy index.html from the parent directory to this directory and open it in an editor:


Replace the text with “This page was reached via OIF Federated SSO” and save:


Rename the file as oiftest.html:



Selecting a Test Account for Federation SSO Testing

The loopback test requires that an account in OID that has an email address populated be used. One can create a new test account, or use an existing account. For this article, the ‘oaamadmin’ account is used for this purpose. In either case, confirm the suitability of the account by opening a browser and navigating to ODSM:


Connect to OID as cn=orcladmin:


Click on the Data Browser tab and navigate to the account that will be used (cn=oaamadmin in this example). Ensure that the email address is populated (if not, enter a dummy email address and click Apply):



Test IDP-Initiated SSO

To confirm that OIF is functioning properly, the following URL will be tested (substitute actual values for the example values):

The first element of the URLs specifies the IDP that the user will authenticated against. The second element specifies the SP that acts as a gateway to a remote resource, and the last element specifies the target resource that the user wishes to access behind the SP. Open a web browser and enter the URL in the address bar:


The browser will redirect to the login page controlled by the IDP. Enter the credentials for the test account and click Sign In:


If login is successful, the browser will redirect to the target page (oiftest.html):



Backing Out the Loopback Test Configuration

The configuration changes for the loopback test must be backed out before the final configuration for FA can be completed.Go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):


Right-click on OIF( and go to Administration > Authentication Engines:


Change Default Authentication Engine to Oracle Access Manager 11g and click Apply:


Right-click on OIF( and go to Administration > Identity Provider:


Uncheck Enable Identity Provider and click Apply:


Right-click on OIF( and go to Administration > Federations. Highlight the IDP for Loopback Testing entry and click Delete:


Click Yes:


The Federations page should now look like this:



At this point, the WLS AdminServer and OIF managed server should be restarted.


Import/Export Metadata for Enterprise Federation

In this section, the process for establishing a federation trust between the FA OIF instance and the enterprise IDP is detailed. In this example, the SAML 2.0 profile will be configured with email address as the Name ID for the federation.

Export SP Metadata

Access the SP metadata by going to the following URL (substitute actual values to this example):


Save the data as sp_metadata.xml:


This file needs to be sent to the administator of the enterprise IDP for import to the IDP federation server(s).

Import Enterprise IDP Metadata

The enterprise IDP administrator must send a copy of the IDP metadata for import into OIF. This file will look something like this:

<?xml version=”1.0″ standalone=”yes” ?>
<md:EntityDescriptor xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata” xmlns:dsig=”” validUntil=”2013-08-09T17:38:44Z” entityID=””><md:IDPSSODescriptor protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol” WantAuthnRequestsSigned=”false”><md:KeyDescriptor use=”signing”><dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIICIzCCAYygAwIBAgIBLDANBgkqhkiG9w0BAQQFADA1MTMwMQYDVQQDEypvYW10
</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo></md:KeyDescriptor><md:KeyDescriptor use=”encryption”><dsig:KeyInfo><dsig:X509Data><dsig:X509Certificate>MIICKTCCAZKgAwIBAgIBBjANBgkqhkiG9w0BAQQFADA4MTYwNAYDVQQDEy1vYW10
</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><md:EncryptionMethod Algorithm=”″></md:EncryptionMethod><md:EncryptionMethod Algorithm=””></md:EncryptionMethod><md:EncryptionMethod Algorithm=””></md:EncryptionMethod><md:EncryptionMethod Algorithm=””></md:EncryptionMethod><md:EncryptionMethod Algorithm=””></md:EncryptionMethod></md:KeyDescriptor><md:ArtifactResolutionService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP” Location=”” index=”1″ isDefault=”true”></md:ArtifactResolutionService><md:SingleLogoutService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”″ ResponseLocation=”″></md:SingleLogoutService><md:SingleLogoutService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”″ ResponseLocation=”″></md:SingleLogoutService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”″ ResponseLocation=”″></md:ManageNameIDService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:SOAP” Location=””></md:ManageNameIDService><md:ManageNameIDService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”″ ResponseLocation=”″></md:ManageNameIDService><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat><md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”″></md:SingleSignOnService><md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=”″></md:SingleSignOnService></md:IDPSSODescriptor></md:EntityDescriptor>

Of note here is the Entity ID:


This is the URL that the IDP is accessed from, and it should be verified at this point that this URL is reachable by an end user.

Open a browser and go to the EM Fusion Middleware Control Console, logging in as the WLS administrator (e.g., ‘weblogic’):


Right-click on OIF( and go to Administration > Federations:


Click Add:


Check Enable Provider and click Browse:


Navigate to the enterprise IDP metadata file, click to highlight it and click Open:


Enter a description (e.g., Enterprise IDP Metadata) and click OK:


Testing Federation with the OIF Test SP Module

The new federation agreement can be tested using the built-in Test SP authentication engine. In Enterprise Manager, navigate to Administration > Service Provider Integration Modules:


Click on the Test SP Engine tab:


Ensure Enable SP Engine is checked (if not, check it and click Apply):


Prepare a Test Account

In order for federation to work, the test account must be present in the OIF identity store as well as the enterprise IDP identity store, and the email address for this account must be present in both places with the identical value. By default, this is the Name ID that the two federation endpoints will use to identify a user.

Open a browser and manually clear cookies and any active sessions:


Enter the following URL (substitute actual values for the example below):


Check Use Default Configuration and click Start SSO:


The browser session will be redirected to the enterprise IDP to authenticate:


Enter the credentials of the test account to login:


If successful, the following summary page will be displayed:



Cutover Fusion Applications SSO to Federated SSO

Open a browser and navigate to the OAM Administration Console, and log in as the OAM administrator:


Navigate to Authentication Schemes > FAAuthScheme:


Change the following parameters:

Challenge URL: (substitute actual hostname and port here)

Challenge Parameters: TAPPartnerId=OIFDAPPartner

and click Apply:


Ensure the change is successful:



The configuration is now complete and can be tested by logging in to the FA homepage.


  1. paul-wgap says:

    Hi Jennifer/Steve,

    I could not find anywhere to post a question in general, so I found the article which seems closest and am hoping you might be able to point me in the right direction.

    We have the following situation:
    We use OAM and federated authentication using an external Identity Provider.
    For all but one of our applications, the normal 2-step authentication is fine, i.e. (1) authenticate with the external IDP via SAML, then (2) check that a corresponding user exists locally (in OID).

    However, for one application, the users will not be in our local OID, so we want to ignore that situation.

    We thought we could define a 2nd IDP, which would simply always return a fixed entry in OID (e.g. PUBLIC), but Oracle has told us OAM does not support 2 IDPs with the same service URL.

    So one of our ideas would be a custom authentication plug-in which could be included in the orchestration steps of the authentication module.

    But it seems to me this custom authentication plug-in would have to be a modified version of one of he out-of-the-box federated authentication plug-ins, which would have 2 different behaviours: (1) the normal 2-step authentication for all but the one application URL, and (2) only the single step authentication for the one application which needs this.

    Do you have any thoughts on this and/or know anywhere else I can turn to for advice?


Add Your Comment