SSO between Fusion and EPM Cloud

Oracle Enterprise Performance Management (EPM) is a robust cloud-based enterprise planning service. EPM is based on Hyperion Planning, and it supports a comprehensive suite of business activities including planning and budgeting, consolidation and close, account reconciliation, profitability and cost management, tax reporting, enterprise data management, and narrative reporting.

Single Sign-On (SSO) is a security activity that enables users belonging to an identity provider to access multiple services such as Oracle EPM Cloud, Oracle Fusion Cloud, etc.
Users use their corporate credentials to authenticate once, for example, to an EPM Cloud instance, and then seamlessly access other configured service providers such as Fusion Cloud or others without being challenged for credentials.

In this blog post we will provide an overview of the general SSO setup process, followed by describing what’s needed to setup SSO between EPM and other applications (focusing specifically on Fusion Cloud, but the discussion applies elsewhere as well).

High-Level SSO Flow

1. Identify a SAML 2.0 compliant Identity Provider ( a.k.a IdP) . This is the component where the user identity(including password, 2FA etc) lives, and where the user logs in. Oracle IDCS, Okta are few of the well known Identity Providers. ( Fusion Cloud, incidentally, is an IdP on its own, which allows for some special situations as we’ll see below )
2. Configure the IdP at both the applications.
3. Register the two applications (a.k.a. Service Providers or SP) at the IdP.
4. And finally make sure the user identity (say the email address) is available in both applications for all the users that need to access the two applications. This can be a bulk-upload process, or some sort of automated periodic user upsert flow.

Now that we understand the high-level flow, we can take a look at the specific steps required to enable SSO for EPM Cloud, and some of the gotchas along the way.

General EPM SSO Steps

Most of the EPM tenants reside on what’s called as Shared Identity Manager or SIM. SIM is an older version of Identity Administration in Oracle Cloud, but most EPM customers use it if they purchase EPM standalone.

With SIM, the process of enabling SSO is documented in detail here , below are the high-level steps :

1. Log on to your Oracle Cloud Account, and navigate to MyServices.
2. Go to the Users tab, and click SSO Configuration subtab.
3. Click ‘Configure SSO’ , and provide IdP metadata(#2 from the high-level flow above) from the chosen Identity Provider, other required details, and then click ‘Test’ to verify SSO.
4. Finally, after the test is successful, the users who need SSO need to be created in SIM and need to be assigned the required roles. Refer to the link here for detailed steps.

With these steps,the user can authenticate to the IdP once, and access EPM Cloud and other configured apps all at once, without having to login again. For example, the customer could choose Oracle IDCS to be their Identity Provider, and have Fusion Cloud and EPM Cloud as two configured SPs, and the customer could log on to IDCS once and access both the applications.

. . .

Now, this setup and the steps work for “most ”of the EPM customers. But sometimes when a customer buys EPM along with Fusion, the provisioning process pre-configures SSO between EPM and Fusion, with Fusion as the IdP.

As mentioned above, Fusion Cloud comes with a fully-featured Identity Management System, and it can act as an IdP on its own.

Customers should check first if SSO has indeed been preconfigured. To confirm that, the easiest way is to look at the EPM access URL. The URL is of the form https://-.us2.oraclecloud.com, and if the identity-domain name is the 4-letter fusion pod name, then SSO has been pre-configured. Otherwise if the identity domain name is of the form ‘a12345’ then SSO hasn’t been preconfigured.

While a pre-configured SSO is a good thing, sometimes it throws customers off because they cannot edit their SSO configuration in MyServices as mentioned above ( on account of it being preconfigured ).

If customers want, they can break this federation by logging an SR with Oracle, and after that they can edit the SSO configuraion in myservices. But breaking this federation is an irreversible activity, and customers should be doubly sure before going through with this.

References

• https://support.oracle.com/epmos/faces/DocumentDisplay?id=2131730.1
• https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/cgsad/3_epmc_sso_config_chap_ora_fusion_integration.html
• https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/cgsad/4_managing_epm_cloud_users_roles_heading.html
• https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/cgsad/3_sso_config_section_header.html