This is first blog in the series of blogs that I am writing to explain identity integration of Oracle Fusion Application with PaaS services using Identity Cloud Service to achieve single-sign-on between services. Here is list of blogs in this series

1. Understanding the Integration Architecture - Fusion Application with Platform services
2. Enable Federation with Fusion Apps as Identity Provider
3. Enable Federation with Identity Cloud Service as Identity Provider
4. Setting up users and roles synchronization between Fusion Apps and Identity Cloud Service
5. Using IDCS OAuth tokens for invoking Fusion Apps rest endpoints.
6. 3-legged Oauth flow to invoke Fusion Apps rest endpoints.
7. Leveraging IDCS OpenID Connect for Fusion Applications

In our cloud journey over the last decade, we enabled our customers with cloud services across the board covering Infrastructure, Platform and Enterprise Software and making them work together in an integrated fashion to solve customer's real time business problems. One of the important aspect of such integration is identity and access management across these services and we are making every effort to make it work seamlessly across our services portfolio and extending it to customer's own identity and access management solutions.

With the release of Oracle Identity Cloud Services which is cloud based Identity and Access Management solution and its availability at the account level will helps the identity integration for Oracle Cloud Services. Starting June 2017, we can see the new cloud account availability on cloud.oracle.com sign-in page along with traditional cloud account -

Going forward, all new customer accounts will be provisioned in Cloud Account with Identity Cloud Service and existing traditional account will be migrated in a phased manner. When the account gets provisioned, customer will get one primordial Identity Cloud Service instance and all his account administrator and service administrators will get created in this IDCS instance. For pricing and feature-set of Identity Cloud Service, please visit here. Given our diverse set of services both home-grown and acquired, have different and disjoint Identity Management Systems, we are looking forward to leverage IDCS as default Identity System for them or supporting integration with IDCS to provide end-to-end identity integration.

In this article, we will explain the architectural patterns which helps in identity integration of Platform Services and Fusion Applications to provide single-sign-on and usage of single identity repository across the board. Same patterns is extended to provide integration with other SAAS services which leverage IDCS.

Current State

It will be useful to understand the current state for Fusion Application and how it work with Other Platform Services today which is explained by following diagram

As illustrated above, Fusion Application uses it own Identity Management System (Oracle IDM) and Platform Services like JCS-SaaS Extension, Integration Cloud, Process Cloud and other SIM based services uses Shared IDM for Identity Management. In order to provide single-sign-on between Fusion Applications and SIM based Platform Services, Fusion Application's Internal IDM is federated with Shared IDM where Fusion IDM acts as identity provider and SIM acts as service provider. All Fusion Application instances which are provisioned after Sept'16 have this federation enabled automatically. In a typical Fusion Application implementation when a employee get hired, his record gets created in FA's Internal IDM which needs to be synchronized in Shared IDM for single-sign-on use-cases to work between Fusion Application and SIM based Platform Services. This can be accomplished using self-service configuration at Fusion Application using these steps.

One important things to note here is about Non-SIM based Platform Services like JCS, SOACS and ACCS, these services currently are not using any identity management system out of the box and hence cannot be federated with Fusion Applications to achieve single-sign-on.

Platform Services with IDCS

As I mentioned before that every account will get one primordial instance of IDCS automatically and this will be leveraged as default Identity Management System. All Platform services will start provisioning pre-wired with IDCS in the new cloud account and will use this IDCS for its identity and access requirement. This topology will look as below -

Fusion Applications with PAAS and IDCS

While PaaS services are using IDCS for IAM requirements, Fusion Application is still using its internal IDM for Identity and Access Management. Fusion Application will soon start provisioning in IDCS based cloud account along with other services but will be using its own internal IDM for IAM requirements. Existing FA pods which are in production will eventually get migrated in the new cloud account with IDCS but will still use its own internal IDM for identity and access management. Topology arising from such non-integrated and integrated FA pods will look like below

In such scenario where Platform Services are using IDCS and FA is using its internal IDM, the requirement of identity integration to achieve single-sign-on and single user footprint will be fulfilled by federating FA's internal IDM with IDCS. For both existing FA pods in production in traditional cloud account and newly-provisioned/migrated FA pods in IDCS based cloud account, it is customer decision when to federate FA with IDCS and to choose who will become Identity Provider and who will be Service Provider depending on their use-cases.

Available Federation options between FA and IDCS

1. Fusion App's Internal IDM as IdP and IDCS as SP - For customers who want to extend their Fusion Apps with custom application on Platform Services and require single-sign-on among these for their users. Such customers are not interested in leveraging other feature of IDCS which require IDCS as Identity Provider.
2. Fusion App's Internal IDM as SP and IDCS as IdP - Customers who want to take full advantage of Identity Cloud Service by leveraging its advance feature like social logins, multi-factor authentication etc along with providing single-sign-on between their Fusion App and other Platform Services to their users, will choose to configure IDCS as Identity Provider in the federation set-up with Fusion Application.

• When IDCS is IDP -
  1. Users can first get created in FA and then synchronized into IDCS
  2. Users can first get created in IDCS and then synchronized into FA and associated with person record in FA

Here is how this topology look like -

Configuration

Federation configuration between Fusion Application and IDCS

1. Manual federation configuration by customer supported by Oracle Operations thru Service Request
2. Self-service User/Role Synchronization thru FA ESS Job from FA to IDCS
3. Self-service configuration for user sync from IDCS to FA

I will explain these configuration in this blog series.

Conclusion

Identity Integration between Fusion Apps and Platform Services can be achieved via Oracle Identity Cloud Service for Fusion Applications extension use-cases with platform services providing single user footprint, single-sign-on among all services, integration with on-premise IDM system along with newer capabilities like social login and multi-factor authentication.