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 wn0210712018 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 an0210712018 _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 37