0210712018 _Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
Fusion Applications Functional Architecture ai Q = MENU
isa = Niet “are
Try Oracle Cloud for Free
SECURITY | Thursday, April 11, 2013
Fusion Applications Single Sign On - Business
User perspective
By: Guest Author
Common Use Cases & How to implement
them (SSO Pilot Website)
The post outlines some of the more prevalent Single Sign On (SSO) use
cases Fusion customers are currently using. It also provides an outline of
work necessary to enable each of these use cases & links to more detailed
technical information.
Case #1: From Corporate Portal
Employees, already authenticated into your corporate portal, should be
able to click on the Fusion Apps link and get access without being
challenged for their username/password as shown below.
-ntpsufologs.oracte.comvfunctonalarchitecturefusion-applications-singl-sign-on-business-user-perspective wn0210712018 Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
From Corporate Portal
eee
Figure #1: SSO from Corporate Portal
Software you'll need:
Most companies will already have a directory (LDAP) that they are using to
store their employees identities. If you already have Single Sign On
configured for any of your applications, then you probably already have a
“Federation Server" inhouse.
If your federation server is:
+ ADFS (Active Directory Federation Server) 2.0 from Microsoft
+ Oracle Identity Federation 11g
... you're all set.
If i's some other Federation Server capable of issuing a SAML 2.0 token,
this is subject to approved by Oracle.
Configuration / Integration Work Needed:
Creating Employees in Fusion Apps: First thing you'll need to plan is how
to create your employee identities in Fusion Applications and how to assign
them the appropriate roles in Fusion Applications (this is required before
Single Sign On will work). For testing purposes, you can just create the
users using the Fusion Applications "Manage Users" or "New Person"
screens and typing them in. If you're a small company, you can continue to
do this for new hires. If you're a large company, refer to the
"Employee/Role data flow" page - this might reflect the flow you need. If it
!ntpsrologsoracl.comvtunctonaarchitectureislon-applications-single-sgn-on-business-user-perspective
an0210712018 _Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
does not, let us know.
When creating the employee in Fusion HCM, the value that you enter as
the "HCM username", should be a unique value also present in your
Federation Server for that employee, as you will need to configure your
Federation Server to send this value as the "Name Id" when it issues the
SAML token for Fusion Applications to consume. [The "Name Id" is just a
unique value that tells Fusion Apps who this user is].
View Co-existence and SSO Presentation for more details.
Configuring your Federation Server & Fusion Applications (Cloud): Then
it's simply a matter of doing some configurations in your Federation Server
and for Oracle's Cloud Operations team to do some configurations in your
Fusion Applications Pod. This part is done via filing a Service Request. The
details of all this are available in My Oracle Support under Note 1477248.1
Embedding URL: Finally you will embed the url into your corporate portal
and your authenticated users will be able to click on the Fusion
Applications link and be taken directly into Fusion Applications without
being challenged again.
Case #2: From a 3rd Party Application
Employees already authenticated to a 3rd party SaaS Application should
be able to click on a Fusion Applications URL and access Fusion
Applications without being challenged for their username/password.
From 3" Party Cloud Application
uaa aan
r
-ntpsufologs.oracte.comvfunctonalarchitecturefusion-applications-singl-sign-on-business-user-perspective 370210712018 _Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
Figure #2: SSO from 3rd Party Application
Software you'll need:
If your employees are already configured for SSO into the 3rd party Cloud
App, then you probably already have all the On-Premise Software needed
in place (LDAP & Federation Server). Refer to Corporate Portal page
Configuration / Integration Work Needed:
Creating Employees in Fusion Applications: Exactly the same as the
“Corporate Portal” use case above.
Configuring your Federation Server & Fusion Applications (Cloud):
Exactly the same as the "Corporate Portal” use case above. Single Sign
On will operate between your On-Premise Identity Provider and Fusion
Applications in exactly the same manner, but your end user will experience
Fusion Applications embedded within your 3rd party Cloud Application (as
long as the 3rd party Cloud Application supports embedding the URL)
Embedding URL: You will embed the URL into the 3rd party Cloud
Application and your authenticated users will be able to click on the Fusion
Applications link & access Fusion Applications screens without being
challenged again
Case #3: Accessing Fusion HCM & Taleo
Employees authenticated against Fusion Apps via SSO, should be able to
access Taleo without being challenged for their username/password.
Accessing Fusion HOM & Taleo
“A Bey = coment
vee na
ie -—---
Figure #3: Accessing Fusion HCM & Taleo
-ntpsufologs.oracte.comvfunctonalarchitecturefusion-applications-singl-sign-on-business-user-perspective 470210712018 _Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
If you wish to Single Sign On into Fusion HCM, you will need to configure
that as outlined in the "Corporate Portal" use case above.
Then you follow the configuration steps to get Taleo SSO working with your
On-Premise IdP. This includes a step of ensuring that the employees that
need to access Taleo are already created in Taleo.
Now once your users are logged into Fusion HCM, they can bring up an
additional tab for Taleo and will be automatically logged into Taleo.
Case #4: Access from Home
All the use cases above should also work when the employee logs in from
home (outside work network)
Accessing Fusion Apps from Home
qujedeve s4qv/s0 Yenere
imeroe TE
Figure #4: Access from Home
Case #5: SSO plus Non-SSO
‘Some of your employees (contractors etc) or partners are not present in
your LDAP and need to be authenticated by Fusion Applications. All the
others need to be authenticated via SSO. NOTE: This is supported as of
Release 7 only.
-ntpsufologs.oracte.comvfunctonalarchitecturefusion-applications-singl-sign-on-business-user-perspective 30210712018 _Fusion Applications Single Sign On - Business User perspective | Oracla Fusion Applications Functional Architecture ang Solutions
SSO plus Non-SSO use case
$80 Flow Non SSO Flow
erry
Us
4 ~
“* ae Federation
Figure #5: SSO plus Non-SSO
As of Release 7, when you click on the Fusion Applications URL, you will
be able to choose between SSO authentication and authentication via
Fusion Applications. Contractors and Partners can choose to authenticate
via Fusion Applications and employees via SSO.
The SSO setup & configuration remains the same as in the "Corporate
Portal" use case above.
References
Co-existence and SSO Presentation
My Oracle Support (MOS) Interlinked documents on Fusion Apps SSO
MOS Note on Configuring Taleo Business Edition
Employee/Role data flow (from SSO Pilot Website)
SSO Pilot Website
Feedback via comments below or email
Join the discussion
Comments ( 2 )
-ntpsufologs.oracte.comvfunctonalarchitecturefusion-applications-singl-sign-on-business-user-perspective er0210712018 __—Fusion Applications Single Sign On - Business User perspective | Oracle Fusion Applications Functional Architecture ané Solutions.
bitps:ologs.oracl.comifunctionalarehitecturfusion-applications-single-sign-on-business-user-perspective a