IDCS Integrations Series Part II:Integrating Fusion Application with IDCS

Overview Last year at OOW, I conducted Hands On Lab on Fusion integration with IDCS. We had a full room of audience with loads of questions. That inspired me to write this blog. One of the most common requirements as Fusion is deployed in OPC is, how to centrally manage users and implement Single Sign-On […]

Migrating your Fusion Applications Auth OHS to a DMZ server

Introduction There maybe a need to expose your application to non-employees outside of your organization such as suppliers who make use of supplier portal. This article is intended to describe how you can do this after you have already provisioned your Fusion Applications environment. Main Article In this article we will describe the steps needed […]

Cloud Security: Seamless Federated SSO for PaaS and Fusion-based SaaS

Introduction Oracle Fusion-based SaaS Cloud environments can be extended in many ways. While customization is the standard activity to setup a SaaS environment for your business needs, chances are that you want to extend your SaaS for more sophisticated use cases. In general this is not a problem and Oracle Cloud offers a great number […]

Cloud Security: Using Fusion Application Web Services with Message Protection

Introduction Oracle Fusion Applications offers a number of WebServices to allow other applications to incorporate the Fusion Applications functionality. To prevent data leakage, these WebServices follow a common security pattern that requires access authentication and message protection using message signing and/or message encryption. To use such a WebService, the WSDL of each service provides all […]

Transport Level Security (TLS) and Java

Know Which Versions of TLS are Supported in Recent Java Versions NOTE:  A more comprehensive examination of TLS and what to examine when setting up web service integrations in Oracle Cloud Saas extensions has been published.  See Transport Layer Security (TLS) and Web Service Connections in SaaS Integrations In the twenty-plus years of the Internet’s […]

Cloud Security: Federated SSO for Fusion-based SaaS

Introduction To get you easily started with Oracle Cloud offerings, they come with their own user management. You can create users, assign roles, change passwords, etc. However, real world enterprises already have existing Identity Management solutions and want to avoid to maintain the same information in many places. To avoid duplicate identities and the related […]

Mass Reset Password-part1 OID

Introduction One of the great features that customers need to be aware of and it could be used, as post-process, on many different situations such as: P2T, T2P and clone is the ability to reset multiple passwords simultaneously. Imagine the customer is scaling out their environment because they need an additional UAT environment. This customer […]

Prepare Your Fusion Applications for Security Audits

Introduction In an enterprise environment it is very common that regulations require regular security audits of the computer systems. The company’s security officer is responsible for facilitating these and may request many reports from the administrators of the respective systems. Very often these reports include user activities for log in, log out, entering wrong passwords, […]

Extending the Oracle Sales Cloud with SOA Suite

Introduction The Oracle Sales Cloud provides an extensive set of features for extending the user interface, the underlying data model, and allows the use of Groovy scripts to extend or adjust the default business logic. If customers have requirements that go beyond these capabilities, Java Cloud Service is a viable option to build new user […]

Disabling Change Password and Forgot Password functionality in FA-IDM

Introduction Oracle Fusion Applications (FA) uses Oracle Identity Management (IDM) capabilities to implement the “change password” and “forgot password” functions. These functions, in turn, are enabled using capabilities provided by Oracle Access Management (OAM) and Oracle Identity Management (OIM). Frequently, in development and test environments, for the sake of convenience, the change password and forgot […]

IDM FA Integration flows

Introduction One of the key aspects of Fusion Applications operations is the Users and Roles management. Fusion Applications uses the Oracle Identity management for its Identity store and policy store by default.This article explains how user and roles flows work from different poin of views, using ‘key’ IDM products for each flow in detail. With […]

Using soapUI for secure, asynchronous web service invocations in Fusion Applications   

Using secure, asynchronous web services Fusion Applications exposes across all of its product families numerous web services that allows for querying, creating and updating of business objects. In this blog we will show how to leverage these services in a secure, asynchronous fashion from a web service client tool such as soapUI. While invoking services […]

Validating the Fusion Applications Security Components During Installations and Upgrades

Introduction   When installing or upgrading Fusion Applications, it is necessary to validate the security components to ensure that they are functioning correctly. This article provides a list of tasks that can be performed to accomplish this. The order of tasks below follow the dependency that the components have on each other so that if […]

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

Introduction 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 […]

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

Introduction 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 […]

Expiration Checklist for Fusion Applications

Two main things when expired will significantly affect the operations of Fusion Applications. These are database passwords and certificates. As such these expiration dates need to be checked and maintained properly.

Check for expiring database account passwords

Fusion Applications have many schema users in the Fusion Application database.  Many of these schema users by default have no expiry date, however some do.  You can check the expiration date for these passwords using sqlplus and connecting to the FA database as sys.  Use the following command to check the expiry_date:
select username, account_status, expiry_date, sysdate from dba_users where expiry_date is not null;
TODO:  Keep track of when database accounts will expire.  When the database accounts will soon expire, update the accounts and reset the expiry_date according to your established corporate security policy requirements.  Note: You can reuse the existing password when resetting these schema accounts.

Check for expiring certificates

Fusion Application will fail when certificates expire.  It’s important to check all certificate stores (JKS for WebLogic and PKCS#12 for OHS) for expiring keys and certificates so that they can be renewed in a controlled and timely manner.


For Fusion JKS Certificates Stores

You should maintain a list of all certificate stores so that they can be located easily.  
The fusion jks stores are fusion_trust.jksand <hostname>_fusion_identity.jks in APPLICATIONS_BASE/fusionapps/wlserver_10.3/server/lib
For each JKS store, use keytool to examine the contents, noting the expiration date for each key and certificate:
$JAVA_HOME/bin/keytool -list -v -keystore <keystore filename>


Note:  fusion_trust.jks contains the keys and certificates in each of the <hostname>_fusion_identity.jks.  When replacing the key and certificates, you must replace each <hostname>_fusion_identity.jks and fusion_trust.jks separately.

For Webgate Certificate

You should note down the expiration date of the webgate certificate and replace them as appropriate.  The webgate certificate is in APPLICATIONS_CONFIG/CommonDomain_webtier/config/OHS/ohs1/webgate/config/simple. To check the certificate expiration date, use keytool to examine the contents:

$JAVA_HOME/bin/keytool -printcert -v -file aaa_cert.pem



For PKCS#12 Certificates Stores

The location of the certificate stores used by FA OHS instances can be found in the OHS configuration files. The following example shows how to determine this:
cd APPLICATIONS_CONFIG/CommonDomain_webtier/config/OHS/ohs1


cat *.conf ./moduleconf/*.conf | grep SSLWallet filename
Each of these should be opened with the orapki utility to examine the content and verify the certificate expiration. The orapki utility is described in detail here:



Super User/Role setup for Common Implementation of Fusion Apps

Hello Everyone!
This post is about preparing the installed IDM/FA for Common implementation of Fusion Applications (FA).  


Please note that this procedure needs to be done for BARE METAL Installation. However for OVM template based installation it has been observed that these steps have been already done as a part of installation. My suggestion for OVM would be to validate these steps and complete any/all of the step(s) as needed.


After the installation of FA, an organization starts the common implementation that involves a  series of tasks shown below. 


This blog is limited to explaining the first 2 tasks in the above diagram. Kindly refer to Getting Started with Fusion Applications : Common Implementation document for  further details.

A little background on why we are doing this.
In Fusion Applications, users along with security are managed by HCM Task flows which require Enterprise structures to be setup.  For setting up these Enterprise structures we need to create specific users in HCM. Initially since there will not be any Enterprise structures, we need to have a Super User who can create appropriate implementation users.

The implementation user created by the super user in turn will be responsible for providing
  1. Users and their Security Management.
  2. Implementation Project Management.
  3. Enterprise Structure creation and management.

As part of our post IDM/FA install, we have to complete  the following two tasks using the OIM system administrator.

  1. Preparing Oracle Fusion Applications Super User for User Management and Configuration


  2. Preparing IT Security Manager Role for User and Role Management




 Before we begin we have to  make sure the following.

  1. FA install is successfully completed. Any RUP install are done and successfully completed.


  • URLs for Oracle FA and OIM are available.



  • OIM system administrator user and Super User (FAAdmin or weblogic_fa or user defined) credentials.


Preparing Oracle Fusion Applications Super User for User Management and Configuration
During the provisioning and installation of Oracle Fusion Application a super user is created by default (FAAdmin or weblogi_fa  etc as provided during the installation). However the email id for this super user may  not be setup correctly during the provisioning and installation. The first task is to make sure the super user has a valid email id as it is mandatory for  User management and configuration.  This could be done in couple of ways

a)      Command Line (Linux)   

Command Line Interface

  1. Open a new Terminal.


  2. Using Vi editor or gedit,  create an ldif file with the following contents (sample.ldif).  I had stored this file along with other property file in the following directory /u01/fastage/prop_files


dn: cn=weblogic_fa, cn=users, dc=mycompany, dc=com


changetype: modify


replace: mail


mail: valid e-mail_address
Note that the super user in this case is “weblogic_fa”.
  1. In the Oracle Identity management domain (IDM), set  the Oracle Home to point to IDM.
$> export MW_HOME=/u01/app/oracle/product/fmw 
$>export ORACLE_HOME=$MW_HOME/idm
  1. Run the ldapmodify command to modify the super user (in this case weblogic_fa) email id.
            $> $ORACLE_HOME/bin/ldapmodify -h -p 389
-D cn=orcladmin  -w Welcome1  -f $HOME/prop_files/superuseremail.ldif
 Note we use the OIM administrator “orcladmin” to effect the email changes to the super user “weblogic_fa”.
  1. Make sure that the command is run without any errors.


  • Run the Reconciliation detailed below (after the GUI Interface for ODSM section)


  1. Log into ODSM using OIM administrator (xelsysadmn).
  1. Click on “connect to directory” and select OID – OID-SSL  and log in as administrator (cn=orcladmin)
  1. Select Data Browser TAB and expand DN “dc=com” which provides the details of the users.
  1. Navigate and select the super user “weblogc_fa”.  On the right side pane, you can edit/change the email address.
  1. Press APPLY to effect the changes.


Run the reconciliation to synch LDAP with  OIM.

6.      Launch the OIM URL and use the OIM system administrator user name and password to sign in.
7.       Click the Advanced link in the upper right of the interface.


            a.        Click Search Scheduled Jobs in the System Management tasks. 

             b.       Enter LDAP User Create and Update Full Reconciliation in the Search Scheduled Jobs field.  


               c.        Select the job in the search results.
    1. Click Run Now to reconcile user updates based on the change log from LDAP.  Scroll down to make sure that the job has run successfully.
The super user created during the installation and provisioning can implement the Oracle Fusion application and administer security. However it does not have roles to create and manage Oracle Fusion Application users. Hence for the IT Security Manager role we add the following OIM roles.
  • Identity User Administrators, which carries user management entitlement


  • Role Administrators, which carries role management entitlement


Note: If you plan to implement your pilot project entirely while signed in as the super user and do not plan to create additional users, then you can skip this step. In reality there would be multiple Fusion Application Users created for various transactions and you are most likely need to perform this step.


  1. Sign in to OIM. Launch the OIM URL and use the OIM system administrator user name and password to sign in.
2.       Click on Administration in the upper right of the interface

                                a.   Search for the IT Security Manager role, and select the role name in the search results.

                               b.       From the Hierarchy tab, click on Inherits From.

                               c.        Click on Add.

                               d.       Select the role category: OIM  Roles and click the find arrow.

                                e.      Select IDENTITY USER ADMINISTRATORS & ROLE ADMINISTRATORS (ctrl + click) and move them to the Add Role list.


                         f.        Click Save. This enables the IT Security Manager with both the roles (Identity user Administrator & Role Administrators) to IT Security Manger.

3.       ALTERNATE for the above task # 2). You may just add SYSTEMADMINISTRATORS role which Inherits from both the roles Identity user Administrator & Role Administrators)  to IT SECURITY MANAGER role


4.       Return to the Welcome to Identity Manager Delegated Administration page,    

  • In the search pane, enter  Xellerate Users in the search field
  • Select organization on the left drop down box and hit search arrow
  • Select the organization name in the search results. The left pane should now display the corresponding details of Xellerate Users.

                           a.        Click the Administrative Roles link in the row of links above the Xellerate Users page.

b.       In the POPUP window Click ASSIGN

                                      c.        In the Filter By Role Name field of the Details window, enter *IT_SECURITY_MANAGER*

                                      d.       Click Find.

                                      e.        Enable Read, Write, Delete, and Assign.

                            f.        Click Assign and Confirm.


  1. Close the window and sign out.
This concludes this post on preparing the IDM/FA installed environment for Common Implementation of Fusion Applications.

A Further Introduction to Oracle IDM and Fusion Apps

Last week I gave an introduction into the Fusion Middleware Security in Fusion Applications.  This week I’d like to expand on that introduction to talk specifically, but still at a high level, about how the the Oracle IDM products fit in Fusion Apps.  To review, here I’m talking specifically about OID, OVD, OAM, OIM, and optionally OIF.

Active Participants
If you are going to take anything away from what I have written or will write about Fusion Apps and IDM let it be this: Do not ignore the Identity and Access Management components of Fusion Applications or take them for granted.

Even more than the other FMW components in Fusion Apps, the IDM components are not black boxes. They are independent products that must be actively managed.

Independently Installed
This starts at the very beginning with the fact that unlike the other FMW components, the IDM components of Fusion Apps is installed separately from the actual Fusion Apps kit. In fact, what I like to call the IDM environment for Fusion Apps is a pre-requisite to the Fusion Apps install itself which in turn asks approximately 100,000 questions about the IDM environment that it will be leveraging. This IDM environment includes its own database and web tiers which are distinct from the Fusion Apps database and web tiers.

This process is really just a specific build out of the Oracle IDM Suite, very similar to what an Oracle IDM Suite customer might do for a traditional enterprise deployment.

So, to successfully deploy Fusion Apps, you must be able to successfully deploy the Oracle IDM suite.

Mission Critical
The IDM components of Fusion Applications are mission critical. If OVD, OID, or OAM aren’t working properly (or God forbid, aren’t working at all) then neither is Fusion Apps. It is that simple.

So, if you want a high available deployment of Fusion Apps, you better make OVD, OID, OAM, and OIM highly available.

If you want to be able to restore a backup of your Fusion Apps environment, you better know how to back the IDM components.

If you want to be able to monitor the health status of your Fusion Apps deployment, you better include the IDM components in that monitoring.

Smart people involved in the deployment and/or management of Fusion Apps will recognize this and give proper attention to deploying and tuning the IDM environment for Fusion Apps in a way that is consistent with the requirements for the total FA deployment.

Skill Sets You’ll Want to Have
During a Fusion Apps deployment and the build out of the IDM environment that is a part of that deployment you’ll want to be able to:

  • Understand the deployment options described in the IDM Enterprise Deployment Guide (Fusion Apps Edition).
  • Be able to use that guide to architect an appropriate IDM build out for your specific Fusion Apps requirements.
  • Be able to install OID, OVD, OAM, OIM, and optionally OIF; along with the related pre-requisite and auxiliary packages such as SOA suite, WLS, and OHS.
  • Be able to tune all the above components.
  • Be able to do basic configuration of each of the listed components. The specifics of what this means varies from component to component and even deployment to deployment.

On an ongoing basis you’ll want to be able to:

  • Enable and analyze debug logging for each component.
  • Monitor each component using Enterprise Manager (EM) or integrate the component with an existing monitoring framework in your enterprise.
  • Be able to take backups of the IDM environment.
  • Be able to start and stop each component.
  • Be able to patch each component.
  • Finally, you’ll still want to have basic configuration and administration knowledge for each component around for expected and unexpected changes and maintenance.

While being able to author complex OAM policies, write custom OVD adaptors, or create complex SOA composites for custom OIM approvals isn’t necessary for most if not all Fusion Apps projects; a foundational proficiency with the Oracle IDM stack where one can install, manage, and monitor each IDM product is required for a successful and stable deployment of Fusion Apps.

In the coming weeks I plan to write more about how to plan for, execute, and verify a successful IDM build out for Fusion Apps.