Oracle White PapermdashCoexistence amp Single Sign On

An Oracle White Paper

July 2012

Coexistence amp Single Sign On

Oracle White PapermdashCoexistence amp Single Sign On

Disclaimer

The following is intended to outline our general product direction It is intended for

information purposes only and may not be incorporated into any contract It is not a

commitment to deliver any material code or functionality and should not be relied upon in

making purchasing decisions The development release and timing of any features or

functionality described for Oraclersquos products remains at the sole discretion of Oracle

Oracle White PapermdashCoexistence amp Single Sign On

Table of Contents

Executive Overview 4

Introduction 4

Concepts amp Terminology 4

Which SSO Solution 6

Which Employee Synchronization Solution 6

SSO Solution Descriptions 6

Federated Identity 6

Common Fusion IAM (Future ndash not supported yet) 8

Federated Identity with Oracle Virtual Directory 9

MS OutlookFusion CRM SSO via Secure Token Service 10

Employee Synchronization 10

Implementation Guidance 12

Implementing the Worker Service 12

Implementing On-Premise to Public Cloud Federation 12

Setting up Oracle Virtual Directory 12

Summary 12

References 13

Feedback 14

Executive Overview This White Paper is intended for a functional audience implementing Fusion Applications in either

On-Premise or Public Cloud mode who need to integrate the introduced Fusion Applications and

provide a Single Sign On experience over the entire ecosystem It describes the most common high

level design patterns for accomplishing Single Sign On with the technologies available today and is

intended as a planning tool towards your SSO solution

The paper does not discuss the ldquoOn Demandrdquo mode of deployment for which the Single Sign On

Solution is also available Please refer to My Oracle Support Note 12453391 for details

After reading this document you should be able to map your SSO requirements into one of the

configurations covered in this paper and understand the Identity Management features and HCM

Services you will need to leverage to support that configuration

Introduction Customers implementing Fusion Applications will typically introduce one or a few applications at a

time in order to take advantage of advanced functionality offered by specific applications When not

implementing Fusion HCM their existing HCM Applications or existing LDAP directory will

usually continue to be the entry point for on boarding new employees

Their Apps Unlimited or Other Applications will often already be running Single Sign On with their

existing LDAP directory The customerrsquos immediate concerns include the following -

How to integrate Fusion Applications with their existing Single Sign On Solution so that their

users can access Fusion Applications links without the need to re-enter their credentials

How to make relevant employee information available in the new Fusion Applications such as

manager hierarchy for approvals routing

How to ensure existing and new employees are automatically provisioned with the appropriate role

within Fusion Applications

Concepts amp Terminology LDAP Is a Directory Service with a standardized hierarchical structure optimized for lookups

Active Directory (AD) ndash Microsoftrsquos implementation of LDAP

Oracle Internet Directory (OID) ndash Oraclersquos implementation of LDAP

Federated identity Is the means of linking a persons electronic identity and attributes stored across multiple distinct systems Federation Server (On-Premise Available Now Public Cloud Available in Release 5) Is a software component that provide users with access to systems and applications located across organizational boundaries Virtual Directory (Available Now) A technology that provides a consolidated view of user identity and related information without having to migrate users into a single enterprise directory infrastructure IAM Identity and Access Management System Fusion IAM Fusion Applications Identity amp Access Management Solution Includes all Identity amp Access Management Components such as Oracle Internet Directory (OID) Oracle Access Manager (OAM) amp OIF (Oracle Identity Federation) Common Fusion IAM (Future) Fusion IAM used across Fusion Applications and other Oracle and Non-Oracle applications Worker Service (Available Now) Fusion HCM service that customers can ldquocallrdquo to create Employees and Fusion IAM users HR2HR (Available now) An ongoing comprehensive co-existence scheme provided by HCM to integrate HCM data from EBS or Peoplesoft into Fusion HCM File Upload (Release 4) A one time flat file upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads into staging tables via a file) Spreadsheet Upload (Release 5) A one time upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads the spreadsheet manually) An older version of spreadsheet upload was available until Release 4 called the csv loader It was a more technical version of spreadsheet loader and is being deprecated in Release 5 Fusion Apps User vs Implementation User An Implementation user exists only in Fusion LDAP but not in the Fusion Applications tables A Fusion Apps user exists in both Fusion LDAP as well as shared HCM tables that are installed with any Fusion Applications Install and the two are linked together

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Oracle White PapermdashCoexistence amp Single Sign On

Disclaimer

The following is intended to outline our general product direction It is intended for

information purposes only and may not be incorporated into any contract It is not a

commitment to deliver any material code or functionality and should not be relied upon in

making purchasing decisions The development release and timing of any features or

functionality described for Oraclersquos products remains at the sole discretion of Oracle

Oracle White PapermdashCoexistence amp Single Sign On

Table of Contents

Executive Overview 4

Introduction 4

Concepts amp Terminology 4

Which SSO Solution 6

Which Employee Synchronization Solution 6

SSO Solution Descriptions 6

Federated Identity 6

Common Fusion IAM (Future ndash not supported yet) 8

Federated Identity with Oracle Virtual Directory 9

MS OutlookFusion CRM SSO via Secure Token Service 10

Employee Synchronization 10

Implementation Guidance 12

Implementing the Worker Service 12

Implementing On-Premise to Public Cloud Federation 12

Setting up Oracle Virtual Directory 12

Summary 12

References 13

Feedback 14

Executive Overview This White Paper is intended for a functional audience implementing Fusion Applications in either

On-Premise or Public Cloud mode who need to integrate the introduced Fusion Applications and

provide a Single Sign On experience over the entire ecosystem It describes the most common high

level design patterns for accomplishing Single Sign On with the technologies available today and is

intended as a planning tool towards your SSO solution

The paper does not discuss the ldquoOn Demandrdquo mode of deployment for which the Single Sign On

Solution is also available Please refer to My Oracle Support Note 12453391 for details

After reading this document you should be able to map your SSO requirements into one of the

configurations covered in this paper and understand the Identity Management features and HCM

Services you will need to leverage to support that configuration

Introduction Customers implementing Fusion Applications will typically introduce one or a few applications at a

time in order to take advantage of advanced functionality offered by specific applications When not

implementing Fusion HCM their existing HCM Applications or existing LDAP directory will

usually continue to be the entry point for on boarding new employees

Their Apps Unlimited or Other Applications will often already be running Single Sign On with their

existing LDAP directory The customerrsquos immediate concerns include the following -

How to integrate Fusion Applications with their existing Single Sign On Solution so that their

users can access Fusion Applications links without the need to re-enter their credentials

How to make relevant employee information available in the new Fusion Applications such as

manager hierarchy for approvals routing

How to ensure existing and new employees are automatically provisioned with the appropriate role

within Fusion Applications

Concepts amp Terminology LDAP Is a Directory Service with a standardized hierarchical structure optimized for lookups

Active Directory (AD) ndash Microsoftrsquos implementation of LDAP

Oracle Internet Directory (OID) ndash Oraclersquos implementation of LDAP

Federated identity Is the means of linking a persons electronic identity and attributes stored across multiple distinct systems Federation Server (On-Premise Available Now Public Cloud Available in Release 5) Is a software component that provide users with access to systems and applications located across organizational boundaries Virtual Directory (Available Now) A technology that provides a consolidated view of user identity and related information without having to migrate users into a single enterprise directory infrastructure IAM Identity and Access Management System Fusion IAM Fusion Applications Identity amp Access Management Solution Includes all Identity amp Access Management Components such as Oracle Internet Directory (OID) Oracle Access Manager (OAM) amp OIF (Oracle Identity Federation) Common Fusion IAM (Future) Fusion IAM used across Fusion Applications and other Oracle and Non-Oracle applications Worker Service (Available Now) Fusion HCM service that customers can ldquocallrdquo to create Employees and Fusion IAM users HR2HR (Available now) An ongoing comprehensive co-existence scheme provided by HCM to integrate HCM data from EBS or Peoplesoft into Fusion HCM File Upload (Release 4) A one time flat file upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads into staging tables via a file) Spreadsheet Upload (Release 5) A one time upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads the spreadsheet manually) An older version of spreadsheet upload was available until Release 4 called the csv loader It was a more technical version of spreadsheet loader and is being deprecated in Release 5 Fusion Apps User vs Implementation User An Implementation user exists only in Fusion LDAP but not in the Fusion Applications tables A Fusion Apps user exists in both Fusion LDAP as well as shared HCM tables that are installed with any Fusion Applications Install and the two are linked together

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Oracle White PapermdashCoexistence amp Single Sign On

Table of Contents

Executive Overview 4

Introduction 4

Concepts amp Terminology 4

Which SSO Solution 6

Which Employee Synchronization Solution 6

SSO Solution Descriptions 6

Federated Identity 6

Common Fusion IAM (Future ndash not supported yet) 8

Federated Identity with Oracle Virtual Directory 9

MS OutlookFusion CRM SSO via Secure Token Service 10

Employee Synchronization 10

Implementation Guidance 12

Implementing the Worker Service 12

Implementing On-Premise to Public Cloud Federation 12

Setting up Oracle Virtual Directory 12

Summary 12

References 13

Feedback 14

Executive Overview This White Paper is intended for a functional audience implementing Fusion Applications in either

On-Premise or Public Cloud mode who need to integrate the introduced Fusion Applications and

provide a Single Sign On experience over the entire ecosystem It describes the most common high

level design patterns for accomplishing Single Sign On with the technologies available today and is

intended as a planning tool towards your SSO solution

The paper does not discuss the ldquoOn Demandrdquo mode of deployment for which the Single Sign On

Solution is also available Please refer to My Oracle Support Note 12453391 for details

After reading this document you should be able to map your SSO requirements into one of the

configurations covered in this paper and understand the Identity Management features and HCM

Services you will need to leverage to support that configuration

Introduction Customers implementing Fusion Applications will typically introduce one or a few applications at a

time in order to take advantage of advanced functionality offered by specific applications When not

implementing Fusion HCM their existing HCM Applications or existing LDAP directory will

usually continue to be the entry point for on boarding new employees

Their Apps Unlimited or Other Applications will often already be running Single Sign On with their

existing LDAP directory The customerrsquos immediate concerns include the following -

How to integrate Fusion Applications with their existing Single Sign On Solution so that their

users can access Fusion Applications links without the need to re-enter their credentials

How to make relevant employee information available in the new Fusion Applications such as

manager hierarchy for approvals routing

How to ensure existing and new employees are automatically provisioned with the appropriate role

within Fusion Applications

Concepts amp Terminology LDAP Is a Directory Service with a standardized hierarchical structure optimized for lookups

Active Directory (AD) ndash Microsoftrsquos implementation of LDAP

Oracle Internet Directory (OID) ndash Oraclersquos implementation of LDAP

Federated identity Is the means of linking a persons electronic identity and attributes stored across multiple distinct systems Federation Server (On-Premise Available Now Public Cloud Available in Release 5) Is a software component that provide users with access to systems and applications located across organizational boundaries Virtual Directory (Available Now) A technology that provides a consolidated view of user identity and related information without having to migrate users into a single enterprise directory infrastructure IAM Identity and Access Management System Fusion IAM Fusion Applications Identity amp Access Management Solution Includes all Identity amp Access Management Components such as Oracle Internet Directory (OID) Oracle Access Manager (OAM) amp OIF (Oracle Identity Federation) Common Fusion IAM (Future) Fusion IAM used across Fusion Applications and other Oracle and Non-Oracle applications Worker Service (Available Now) Fusion HCM service that customers can ldquocallrdquo to create Employees and Fusion IAM users HR2HR (Available now) An ongoing comprehensive co-existence scheme provided by HCM to integrate HCM data from EBS or Peoplesoft into Fusion HCM File Upload (Release 4) A one time flat file upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads into staging tables via a file) Spreadsheet Upload (Release 5) A one time upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads the spreadsheet manually) An older version of spreadsheet upload was available until Release 4 called the csv loader It was a more technical version of spreadsheet loader and is being deprecated in Release 5 Fusion Apps User vs Implementation User An Implementation user exists only in Fusion LDAP but not in the Fusion Applications tables A Fusion Apps user exists in both Fusion LDAP as well as shared HCM tables that are installed with any Fusion Applications Install and the two are linked together

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Executive Overview This White Paper is intended for a functional audience implementing Fusion Applications in either

On-Premise or Public Cloud mode who need to integrate the introduced Fusion Applications and

provide a Single Sign On experience over the entire ecosystem It describes the most common high

level design patterns for accomplishing Single Sign On with the technologies available today and is

intended as a planning tool towards your SSO solution

The paper does not discuss the ldquoOn Demandrdquo mode of deployment for which the Single Sign On

Solution is also available Please refer to My Oracle Support Note 12453391 for details

After reading this document you should be able to map your SSO requirements into one of the

configurations covered in this paper and understand the Identity Management features and HCM

Services you will need to leverage to support that configuration

Introduction Customers implementing Fusion Applications will typically introduce one or a few applications at a

time in order to take advantage of advanced functionality offered by specific applications When not

implementing Fusion HCM their existing HCM Applications or existing LDAP directory will

usually continue to be the entry point for on boarding new employees

Their Apps Unlimited or Other Applications will often already be running Single Sign On with their

existing LDAP directory The customerrsquos immediate concerns include the following -

How to integrate Fusion Applications with their existing Single Sign On Solution so that their

users can access Fusion Applications links without the need to re-enter their credentials

How to make relevant employee information available in the new Fusion Applications such as

manager hierarchy for approvals routing

How to ensure existing and new employees are automatically provisioned with the appropriate role

within Fusion Applications

Concepts amp Terminology LDAP Is a Directory Service with a standardized hierarchical structure optimized for lookups

Active Directory (AD) ndash Microsoftrsquos implementation of LDAP

Oracle Internet Directory (OID) ndash Oraclersquos implementation of LDAP

Federated identity Is the means of linking a persons electronic identity and attributes stored across multiple distinct systems Federation Server (On-Premise Available Now Public Cloud Available in Release 5) Is a software component that provide users with access to systems and applications located across organizational boundaries Virtual Directory (Available Now) A technology that provides a consolidated view of user identity and related information without having to migrate users into a single enterprise directory infrastructure IAM Identity and Access Management System Fusion IAM Fusion Applications Identity amp Access Management Solution Includes all Identity amp Access Management Components such as Oracle Internet Directory (OID) Oracle Access Manager (OAM) amp OIF (Oracle Identity Federation) Common Fusion IAM (Future) Fusion IAM used across Fusion Applications and other Oracle and Non-Oracle applications Worker Service (Available Now) Fusion HCM service that customers can ldquocallrdquo to create Employees and Fusion IAM users HR2HR (Available now) An ongoing comprehensive co-existence scheme provided by HCM to integrate HCM data from EBS or Peoplesoft into Fusion HCM File Upload (Release 4) A one time flat file upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads into staging tables via a file) Spreadsheet Upload (Release 5) A one time upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads the spreadsheet manually) An older version of spreadsheet upload was available until Release 4 called the csv loader It was a more technical version of spreadsheet loader and is being deprecated in Release 5 Fusion Apps User vs Implementation User An Implementation user exists only in Fusion LDAP but not in the Fusion Applications tables A Fusion Apps user exists in both Fusion LDAP as well as shared HCM tables that are installed with any Fusion Applications Install and the two are linked together

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Federated identity Is the means of linking a persons electronic identity and attributes stored across multiple distinct systems Federation Server (On-Premise Available Now Public Cloud Available in Release 5) Is a software component that provide users with access to systems and applications located across organizational boundaries Virtual Directory (Available Now) A technology that provides a consolidated view of user identity and related information without having to migrate users into a single enterprise directory infrastructure IAM Identity and Access Management System Fusion IAM Fusion Applications Identity amp Access Management Solution Includes all Identity amp Access Management Components such as Oracle Internet Directory (OID) Oracle Access Manager (OAM) amp OIF (Oracle Identity Federation) Common Fusion IAM (Future) Fusion IAM used across Fusion Applications and other Oracle and Non-Oracle applications Worker Service (Available Now) Fusion HCM service that customers can ldquocallrdquo to create Employees and Fusion IAM users HR2HR (Available now) An ongoing comprehensive co-existence scheme provided by HCM to integrate HCM data from EBS or Peoplesoft into Fusion HCM File Upload (Release 4) A one time flat file upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads into staging tables via a file) Spreadsheet Upload (Release 5) A one time upload mechanism (with some limited update capability) provided by HCM to integrate employee data into Full HCM Fusion Applications from any source (Customer loads the spreadsheet manually) An older version of spreadsheet upload was available until Release 4 called the csv loader It was a more technical version of spreadsheet loader and is being deprecated in Release 5 Fusion Apps User vs Implementation User An Implementation user exists only in Fusion LDAP but not in the Fusion Applications tables A Fusion Apps user exists in both Fusion LDAP as well as shared HCM tables that are installed with any Fusion Applications Install and the two are linked together

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Which SSO Solution The first step is to identify which SSO Solution you need

SSO Solution

1 If you are using Fusion Apps Public Cloud your SSO solution will be via Federated Identity

If you are using Fusion Apps On-Premise you can achieve SSO via Federated Identity

with or without Virtual Directory

2 If you are using Fusion CRM Public Cloud your MS Outlook Integration with Fusion Apps is

via the Secure Token Service in Release 5

Which Employee Synchronization Solution 1 If new employees are on boarded in Fusion Apps your Integration Direction will be Fusion

Apps to 3rd Party LDAP In this case you can leverage an HCM BI Publisher report to upload

employee data into your 3rd Party LDAP

2 If new employees are on boarded into Apps UnlimitedCustom apps first integration direction

will be into Fusion Apps

If running Fusion HCM you may need to use HR2HR Integration

If running Non-HCM Fusion Apps you could Integrate via the lighter weight Worker

Service use Spreadsheet Upload or if you are running CRM Public Cloud use the CRM

upload utility for HCM employees You could also manually enter the employee

3 If new employees are onboarded in one system and subsequent updates are made in another

system (eg email address) then a combination of integration schemes described will need to be

employed

SSO Solution Descriptions

Federated Identity If your Fusion Apps are deployed in a Public Cloud mode from Release 5 onwards you will be able

to request Federation to authenticate your employees via your In-House Identity Provider into

Fusion Apps A pre-requisite for this to work is that the employee must first already exist in the

Fusion IAM instance (this will be used to ldquomaprdquo the identities during Federation) Additional Pre-

requisites are outlined in the Process Document entitled ldquoCo-existence and SSO ndash SSO Enablement

Process for Public Cloud Customers on Release 5rdquo (See References at End) Three common

deployments for Federated Identity on Cloud are shown below

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Figure 1 Fusion HCM (Onboard in cloud)

Figure 2 Fusion HCM (On boarding in Apps Unlimited)

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Figure 3 CRM or ERP Public Cloud (With Shared HCM)

Common Fusion IAM (Future ndash not supported yet)

If you are currently using Fusion IAM with your Oracle AU Applications and are not using a 3rd

party LDAP solution an option to consider is to share your Fusion IAM instance for Single Sign On

to both your AU Apps and Fusion Apps

You will already have your employees in the Fusion IAM instance and only need appropriate roles

assigned for Fusion Apps You might also need to have them created as ldquoFusion Apps Usersrdquo

Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your

users are created as ldquoFusion Apps Usersrdquo

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your options

for accomplishing this

Cautionary Note

There are currently several restrictions with doing this so itrsquos not recommended until itrsquos officially supported (Leaving the documentation in here for future reference)

One restrictions is the following

Fusion IAM has a global IAM configuration setting called ldquoSSO Only Moderdquo flag If this flag is set to ldquoTruerdquo Fusion IAM will do authentication only authorization must be managed by the Apps being accessed If itrsquos set to ldquofalserdquo Fusion IAM can do both ldquoauthenticationrdquo and ldquoauthorizationrdquo

Currently Fusion Applications are certified with this flag set to ldquoTruerdquo So the recommendation is to set this flag to ldquoTruerdquo to avoid any potential performance issues with Fusion Applications

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

With this flag set to ldquoTruerdquo any applications that require Authorization by Fusion IAM cannot use the Common Fusion IAM Instead they can deploy a separate IAM instance or implement Application level authorization

Figure 4 Common Fusion IAM shared between Apps Unlimited amp Fusion Apps (Future)

Federated Identity with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps UnlimitedCustom

Applications and you would like to get Single Sign On working you will also use Federated Identity

between the two systems However you have the option of also setting up a split profile (Virtual

Directory2) between Fusion IAM and your 3rd party LDAP This means that Fusion IAM will have

visibility to all your LDAP users However you might still need to consider synchronizing

employees from LDAP to Fusion Apps This is because

You may need ldquoFusion Apps Usersrdquo instead of just ldquoImplementation usersrdquo that exist only

in Fusion LDAP (for example for approvals etc)

LDAP users visible in Fusion IAM via Virtual Directory will still need to have the

appropriate roles assigned You could accomplish this in virtual directory by making Active

Directory roles members of Fusion IAM roles or you could choose to do it via auto-

provisioning rules in HCM (to leverage auto-provisioning rules a Fusion Apps User needs

to be created)

The ldquoFusion Non-HCMrdquo section under the Employee Synchronization below explains your

options for accomplishing this

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Figure 5 SSO via Federation Oracle Virtual Directory between 3rd Party LDAP amp Fusion IAM

MS OutlookFusion CRM SSO via Secure Token Service A special case SSO solution is the CRM Public Cloud Solution for Integrating Outlook with Fusion

Apps so opportunities contacts etc can be synchronized into Outlook In Release 5 your SSO On-

Premise SSO credentials need to be provided when logging into Outlook These will be used to

retrieve a SAML token from the Secure Token Service and the SAML token is used to call the CRM

web services to synchronize data

Prior to Release 5 your FA credentials had to be provided and were used directly to invoke CRM

web services

Employee Synchronization The direction of employee synchronization depends on whether you are on boarding new employees into your new Fusion Applications or whether you are on boarding new employees into your existing On-Premise Applications first

Fusion Apps To 3rd Party LDAP If employees are being on boarded into Fusion HCM Public Cloud they will need to be synchronized to your On-Premise LDAP This can be accomplished via an HCM provided User

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

Data Extract (BI Publisher Report) Through a Functional Setup Manager task under ldquoDefine Common HCM Configurationsrdquo the output format of the report can be changed into the form that is expected by your On-Premise LDAP and output options can be specified (ie the report can be emailed or posted to a specified site format can be excel xml flat file pdf etc) The report output can then be viewed and downloaded and used to upload employees into your On-Premise LDAP Details of this solution will be made available in Release 5 Look out for an ldquoIdentity Sync Cookbookrdquo on My Oracle Support

On-Premise Applications To Fusion Apps If employees are being on boarded first into your On-Premise HCM application then they need to be synchronized from your On-Premise Application to Fusion Apps The specific integration mechanism you could use here depends on whether you are running HCM Public Cloud and need more employee details in Public Cloud or whether you are running CRM or ERP Public Cloud and need the bare minimum employee attributes It may also depend on whether you with to leverage auto-provisioning functionality within Fusion HCM to auto-provision roles to employees in Fusion Apps

Fusion HCM HR2HR (Available Now) ndash If you are running EBS HR (120 or 121) or Peoplesoft HR (89) and want to integrate employees to Fusion HCM (Talent Management or Compensation) then HR2HR synchronization will probably meet your requirements better This offers real time synchronization from EBS or Peoplesoft into Fusion HCM Spreadsheet Loader (Available Release 5)ndash This will be available in Release 5 It works as follows

You go to an HCM screen and download a spreadsheet to your desktop (In Public Cloud mode you may need to download a small client app as well)

You populate the spreadsheet and upload it back into Fusion HCM where the data gets uploaded into staging tables

You run the batch upload program from Fusion HCM and it uploads the data from the staging tables

If you are running some other HR system (Not Peoplesoft or EBS) and wish to integrate employees to Fusion HCM the spreadsheet loader offers a relatively user friendly mechanism for a one-time upload It has some limited update capabilities as well NOTE ndash The old more technical version of Spreadsheet Loader that was available via My Oracle Support in RUP 1 and was intended for Non-HCM customers will be deprecated in Release 5 File Loader (Available Release 4)ndash This is available in Release 4 It is a little more technical to use than the Spreadsheet loader but is better for large volumes of data It allows files based upload directly into the staging tables From that point on it works the same as the Spreadsheet Loader

Fusion Non-HCM If you need minimal employee details the overhead of the heavyweight HR2HR integration may not be the best option In that case if you need real time synchronization our recommended approach

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

is to use HCMrsquos worker service - Refer to ldquoCo-existing and SSO ndash Implementing the Worker Servicerdquo (See References at end) for more details on using the worker service The Worker Service has the additional capability that if you pass it the GUID of an existing Fusion IAM employee then when it creates an employee it will not create a duplicate IAM user but will instead link the Fusion employee to the matching IAM user (the IAM user may physically exist in Fusion IAM or may be merely ldquovisiblerdquo via Virtual Directory) This feature can be leveraged for achieving ldquoSSO via Common Fusion IAMrdquo and for ldquoFederated Identity via Oracle Virtual Directoryrdquo as in both these cases the user already exists (or is visible in) Fusion IAM Other options for lighter weight synchronization into Fusion Apps include

One-Time CRM Upload of HCM Employees [Functional Setup Manager Task Manage File Import Activities]

Manual Entry of the employee into the Fusion Apps Screens

Role Provisioning In Fusion shared HCM role provisioning rules can be created during implementation which will ensure that the correct Fusion roles are assigned when employees are interfaced into or created in Fusion HCM

Implementation Guidance This section is intended at providing links to relevant technical or procedural material to make it

easier for customers attempting to implement one of the described configurations

Implementing the Worker Service Refer to the following Oracle Technical White Paper Co-Existence and SSO - Implementing the Worker Service

Implementing On-Premise to Public Cloud Federation Refer to the following Oracle Process Document Co-Existence and SSO - SSO Enablement Process

Setting up Oracle Virtual Directory Standard documentation contains details of how to setup and configure Oracle Virtual Directory Refer to httpdocsoraclecomcdE15523_01install1111e12002ovdhtm

Summary

SSO PATTERNS

FUSION APPS

DEPLOYMENT

ON-PREMISE LDAP SOLUTION

Public Cloud Any SSO via Federation

On-Premise Fusion IAM SSO via Federation~ OR Common Fusion IAM between

Apps Unlimited amp Fusion Apps (Future)

On-Premise 3rd

Party SSO via Federation~

~ With Virtual Directory

USER SYNC

ONBOARD

NEW

EMPLOYEES

IN

FUSION APPS

DEPLOYMENT

PROPOSED SOLUTIONS

Fusion HCM Public Cloud BI Publisher Report Upload into On-Premise LDAP

Fusion HCM On-Premise Will happen automatically via SPML apirsquos since both

Fusion IAM and Fusion HCM are On-Premise

Legacy HCM (Either) HR2HR or Spreadsheet Upload (Release 5 version)

Legacy Non-HCM (Either) Worker Service OR Manual Entry OR CRM Upload of

HCM Employees

References 1 Oracle Public Cloud Applications FAQ - Section III Subsection ldquoIntegration with Existing

Security Infrastructurerdquo Question 4

(httpmyoraclecomcontentwebCNT384193levelid=r_s_ov_dd|rad=dd|pt=Frequently20Asked2

0Questions2028FAQ29|sstr=httpmyoraclecomcontentwebcnt842719)

2 Co-Existence and SSO The SSO Enablement Process for Public Cloud Customers on

Release 5 [My Oracle Support Note 14772451]

3 Co-Existence and SSO ndash Implementing the HCM Worker Service [My Oracle Support Note

14772421]

4 HCMrsquos Release 5 Spreadsheet Upload Utility Identity Sync Cookbook ndash available shortly on

My Oracle Support

5 HR to HR Integration [My Oracle Support Notes 14608681 amp 14608691]

Feedback For any follow up QuestionsCommentsSuggestions email kiranmundyoraclecom

Coexistence and SSO

May 2012

Author Kiran mundy

Contributior Vamsi Motukuru

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores CA 94065

USA

Worldwide Inquiries

Phone +16505067000

Fax +16505067200

oraclecom

Copyright copy 2009 Oracle andor its affiliates All rights reserved This document is provided for information purposes only and

the contents hereof are subject to change without notice This document is not warranted to be error-free nor subject to any other

warranties or conditions whether expressed orally or implied in law including implied warranties and conditions of merchantability or

fitness for a particular purpose We specifically disclaim any liability with respect to this document and no contractual obligations are

formed either directly or indirectly by this document This document may not be reproduced or transmitted in any form or by any

means electronic or mechanical for any purpose without our prior written permission

Oracle is a registered trademark of Oracle Corporation andor its affiliates Other names may be trademarks of their respective

owners

0109