1. Configure single sign-on between Oracle Integration and Oracle Fusion Applications
  2. Learn About Configuring Single Sign-on Between Oracle Integration and Oracle Fusion Applications

Learn About Configuring Single Sign-on Between Oracle Integration and Oracle Fusion Applications

Configure single sign-on (SSO) between Oracle Integration and Fusion Applications so that users don’t have to re-authenticate when they access a process that’s embedded in Fusion Applications.

You can integrate Oracle Integration processes with Oracle Fusion Applications by embedding a process UI snippet in a Fusion application (such as CX, ERP, or HCM). This allows the customers to access the process when they need it without having to open another application. Configuring single sign-on for these two products makes this integration seamless and allows the user to authenticate only once.

Embedding processes in a Fusion application lets you extend the functionality of the application, reduces the number of applications the user has to open, and simplifies the user's work.

These are some of the actions you can perform from a Fusion application:

  • start a process
  • monitor your tasks
  • approve or reject a request

Depending on the action you want to access from the Fusion application, you may need to embed a start activity, the task list, or a human task. You may embed multiple process components in the same Fusion application.

To take full advantage of this integration, you need to configure single sign-on so that the user doesn't need to re-login each time they want to perform a process action.

This image is described in the surrounding text.

After configuring this three-part federation:

  • When the end user logs in to Oracle Fusion Applications, Oracle Access Manager sends the user credentials to Oracle Identity Cloud Service. In turn, Oracle Identity Cloud Service authenticates these credentials using Microsoft Active Directory Federation Service.
  • When the user opens an embedded process, Oracle Identity Cloud Service sends the user credentials to Microsoft Active Directory Federation Service for authentication. Because the end user has already logged in through Oracle Fusion Applications, the session is already open and the user doesn't need to log in again.
  • The other applications used in this business organization also use Microsoft Active Directory Federation Service to authenticate their users.

Architecture

This is a three-part federation that lets you configure Single Sign-on between Oracle Fusion Applications, Oracle Integration, and Microsoft Active Directory Federation Service.

When you authenticate from Oracle Fusion Applications, Oracle Access Manager acts as the service provider to Oracle Identity Cloud Service and, in turn, the latter acts as the service provider to Microsoft Active Directory Federation Service.

When you authenticate from Oracle Integration, Oracle Identity Cloud Service acts as the service provider to Microsoft Active Directory Federation Service.

This configuration uses Microsoft Active Directory Federation Service as the identity provider.

The image is described in the surrounding text.

In this configuration, when a user logs in to Oracle Fusion Applications:

  1. Oracle Fusion Applications authenticates the user's credentials against Oracle Access Manager.
  2. In turn, Oracle Access Manager authenticates the user's credentials against Oracle Identity Cloud Service.
  3. Finally, Oracle Identity Cloud Service authenticates the user's credentials against Microsoft Active Directory Federation Service.

When a user accesses a process embedded in a Fusion application:

  1. Instead of prompting the user to log in again, Oracle Integration uses the credentials that the user entered when they logged in to Oracle Fusion Applications to authenticate the user against Oracle Identity Cloud Service.
  2. In turn, Oracle Identity Cloud Service authenticates the user's credentials against Microsoft Active Directory Federation Service.

Configuring Microsoft Active Directory Federation Service is optional. Instead, you may choose to use Oracle Identity Cloud Service as the identity provider in a two-part federation, or you may choose to use a three-part federation using an identity provider that supports SAML 2.0. Your selection generally depends on the identity provider that your business is using for other applications.

The SAML 2.0 supported identity providers include:
  • AuthAnvil
  • Big IP F5 APM
  • CA Single Sign-on formerly CA SiteMinder
  • Centrify
  • Entrust GetAccess
  • ForgeRock OpenAM
  • Google IDP
  • IBM Security Access Manager
  • IBM Tivoli Access Manager
  • Microsoft Active Directory Federation Server 2.0 and greater
  • Microsoft Azure Active Directory
  • NetIQ Access Manager
  • Okta 6.0 and greater (SAML 2.0 compliant versions only)
  • OneLogin
  • Open SAML
  • Oracle Access Management 11gR2 PS3 and greater
  • Oracle Identity Cloud Service
  • Oracle Identity Federation 11g and greater
  • Ping Federate 6.0 and greater
  • Ping One
  • SailPoint Identity
  • SecureAuth
  • Shibboleth 2.4.0 and greater
  • SimpleSAMLphp
  • SSO EasyConnect
  • SURF conext
  • WSO2 Identity Server

About Required Services, Products, and Roles

This solution requires the following services, products, and roles:

  • Oracle Integration

  • Oracle Oracle Fusion Applications

  • Oracle Identity Cloud Service

These are the roles needed for each service.

Service Name: Role Required to...
Oracle Integration: Administrator Test the federated single sign-on configuration.
Oracle Fusion Applications: Administrator Configure single sign-on between Oracle Fusion Applications and Oracle Identity Cloud Service.
Oracle Identity Cloud Service: Administrator
  • Configure single sign-on between Oracle Fusion Applications and Oracle Identity Cloud Service.
  • Configure single sign-on between Microsoft Active Directory Federation Service and Oracle Identity Cloud Service

See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.