Oracle White PaperCoexistence & Single Sign On

An Oracle White Paper

July 2012
Coexistence & Single Sign On



Oracle White PaperCoexistence & 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 Oracles products remains at the sole discretion of Oracle.




Oracle White PaperCoexistence & Single Sign On



Table of Contents

Executive Overview ........................................................................... 4
Introduction ....................................................................................... 4
Concepts & Terminology ............................................................... 4
Which SSO Solution? .................................................................... 6
Which Employee Synchronization Solution? .................................. 6
SSO Solution Descriptions ................................................................ 6
Federated Identity .......................................................................... 6
Common Fusion IAM (Future not supported yet) ........................ 8
Federated Identity, with Oracle Virtual Directory ............................ 9
MS Outlook/Fusion 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 On Demand mode of deployment, for which the Single Sign On
Solution is also available. Please refer to My Oracle Support Note 1245339.1 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 customers 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 & Terminology
LDAP
Is a Directory Service with a standardized hierarchical structure, optimized for lookups.
Active Directory (AD) Microsofts implementation of LDAP
Oracle Internet Directory (OID) Oracles implementation of LDAP




Federated identity
Is the means of linking a person's 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 & Access Management Solution. Includes all Identity & Access
Management Components such as Oracle Internet Directory (OID), Oracle Access Manager (OAM)
& 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 call 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 3
rd
Party LDAP. In this case you can leverage an HCM BI Publisher report to upload
employee data into your 3
rd
Party LDAP.
2. If new employees are on boarded into Apps Unlimited/Custom 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 map the identities during Federation). Additional Pre-
requisites are outlined in the Process Document entitled Co-existence and SSO SSO Enablement
Process for Public Cloud Customers on Release 5 (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 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 Fusion Apps Users.
Auto-provisioning Rules within Fusion shared HCM can be leveraged to assign roles once your
users are created as Fusion Apps Users.
The Fusion Non-HCM section under the Employee Synchronization below explains your options
for accomplishing this.
Cautionary Note:
There are currently several restrictions with doing this, so its not recommended until its officially supported. (Leaving the
documentation in here for future reference).
One restrictions is the following:
Fusion IAM has a global IAM configuration setting called SSO Only Mode flag. If this flag is set to True, Fusion IAM will do
authentication only, authorization must be managed by the Apps being accessed. If its set to false, Fusion IAM can do both
authentication and authorization.
Currently Fusion Applications are certified with this flag set to True. So the recommendation is to set this flag to True to
avoid any potential performance issues with Fusion Applications.



With this flag set to True, 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 & Fusion Apps (Future)

Federated Identity, with Oracle Virtual Directory

If you are currently using a 3rd party LDAP with your On-Premise Apps Unlimited/Custom
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
Directory
2
) 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 Fusion Apps Users instead of just Implementation users 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 Fusion Non-HCM section under the Employee Synchronization below explains your
options for accomplishing this.





Figure 5. SSO via Federation: Oracle Virtual Directory between 3rd Party LDAP & Fusion
IAM

MS Outlook/Fusion 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 3
rd
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 Define
Common HCM Configurations, 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
Identity Sync Cookbook 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) If you are running EBS HR (12.0 or 12.1) or Peoplesoft HR (8.9) 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) 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 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) 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 HCMs worker service - Refer to Co-existing and SSO Implementing the Worker
Service (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 visible via Virtual Directory).

This feature can be leveraged for achieving SSO via Common Fusion IAM, and for Federated
Identity via Oracle Virtual Directory 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
http://docs.oracle.com/cd/E15523_01/install.1111/e12002/ovd.htm
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 & Fusion Apps (Future)
On-Premise 3
rd
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 apis 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 Integration with Existing
Security Infrastructure, Question # 4.
(http://my.oracle.com/content/web/CNT384193?levelid=r_s_ov_dd|rad=dd|pt=Frequently%20Asked%2
0Questions%20%28FAQ%29|sstr=http://my.oracle.com/content/web/cnt842719)
2. Co-Existence and SSO: The SSO Enablement Process for Public Cloud Customers on
Release 5 [My Oracle Support Note 1477245.1]
3. Co-Existence and SSO Implementing the HCM Worker Service [My Oracle Support Note
1477242.1]
4. HCMs Release 5 Spreadsheet Upload Utility: Identity Sync Cookbook available shortly on
My Oracle Support.
5. HR to HR Integration [My Oracle Support Notes 1460868.1 & 1460869.1]



Feedback
For any follow up Questions/Comments/Suggestions email kiran.mundy@oracle.com





Coexistence and SSO
May 2012
Author: Kiran mundy
Contributior: Vamsi Motukuru

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com





Copyright 2009, Oracle and/or 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 and/or its affiliates. Other names may be trademarks of their respecti ve
owners.
0109