The notion of a user is the most common reason for misunderstanding and confusion. When we mention a user, we often think of the person who is allowed to use an application. However, nearly every application has a different user structure implemented. The challenge is to find a common ground for these differing user structures and a way to provision them, i.e. push the user information, into the applications.
In today's connected and integrated world, enterprises usually maintain a single user identity store for all users and their passwords (often referred to as an Enterprise Identity Store). Combined with a state of the art Federated Single Sign-on technique like SAML 2.0 or OpenID Connect, this Enterprise Identity Store acts as the Identity Provider for all connected services, also known as Service Providers.
A successful authentication in a Federated SSO scenario happens at the Identity Provider and the issued token will be used by the Service Provider to "link" the authenticated user to a user identity stored at the Service Provider.
This article explains how Enterprise Identity Store users, which have been provisioned to Fusion Applications Cloud, are turned into users that have the required permissions to behave as expected.
In Oracle Fusion Applications Cloud Applications, a user consists of a User Account and a related Worker or Person structure. The User Account is required for a successful login while the Worker or Person structures tell Fusion Applications Cloud what the User is authorized to do.
Recreating Enterprise Identities in Fusion Applications Cloud manually, for example by hiring a person, can lead to duplicate or misspelled entries and should be avoided. To ensure that Enterprise Identities are configured correctly in Fusion Applications Cloud, they should be provisioned to Fusion Applications Cloud automatically. However, this provisioning of an Enterprise Identity only creates a User Account and does not create any of the related structures. As a result the Enterprise User might be able to log into Fusion Applications Cloud but has no permissions to do anything useful.
To allow Enterprise Users to use Fusion Applications Cloud with the related role assignments, these Enterprise Users must be provisioned first and the Fusion Applications Cloud structures must be created and linked to the related User Account. This process has these steps:
The next sections show these steps in detail.
Before we delve into the steps in detail, we take a quick look at the User name Generation Rule. By default, Fusion Applications Cloud creates the user account structure as instructed by the User Name Generation Rule which defines how the user name is created. It allows the following user name generation schemes:
To avoid name conflicts, Fusion Applications Cloud can also be instructed to create a unique name. The Generation Rule can be configured in the Fusion Applications Cloud Security Console (see picture).
However, when provisioning users from Enterprise Identity Stores, the Generate system name when generation rule fails may be turned off in order to prevent duplicate User Account creation for the same user.
To provision a user into Fusion Applications Cloud many options are available:
All of these options use the Fusion Applications Cloud SCIM API to provision the Enterprise User to Fusion Applications Cloud. This will create the User Account structure in Fusion Applications Cloud, which creates the minimal user information required to successfully complete the Federate SSO login flow.
When user provisioning has been completed for an Enterprise User, this user can start using Fusion Applications Cloud, but no permissions are granted to this user and Fusion Applications Cloud cannot be used in the intended way.
The second step is to create the Worker or Person structure. To do this we simply hire a person. Once a Person has been hired, Fusion Applications Cloud will use the User Name Creation Rule to create a new User Account structure. If this process finds a User Account structure without a person id or party id, and the user name matches the User Name Generation Rule, the Worker structure and the User Account structure will be linked together to form a complete structure.
Hiring a Person can be done manually through the Fusion Applications Cloud UI or in batch mode through the Fusion Applications Cloud services. The next sections explain these steps for UI or Batch mode in detail.
The UI mode is a common way to create a Fusion Applications Cloud Worker structure. This is normally done by Human Resources personnel.
To create a Fusion Applications Cloud Worker structure in batch mode, an HCM Data Loader (HDL) file structure must be used:
METADATA|Worker|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|PersonNumber|StartDate|DateOfBirth|ActionCode MERGE|Worker|HCM_SAMPLE-001|SSID1_P_SAMPLE304WRKR_1|2017/01/27|4712/12/31|P_SAMPLE304WRKR_1|2017/01/27|1970/01/01|HIRE METADATA|PersonName|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|PersonId(SourceSystemId)|NameType|LegislationCode|Title|LastName|FirstName|MiddleNames MERGE|PersonName|HCM_SAMPLE-001|SSID1_P_SAMPLE304PN_1|2017/01/27|4712/12/31|SSID1_P_SAMPLE304WRKR_1|GLOBAL|US|MR.|Lastname|Firstname|X METADATA|PersonLegislativeData|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|PersonId(SourceSystemId)|LegislationCode|Sex|MaritalStatus MERGE|PersonLegislativeData|HCM_SAMPLE-001|SSID1_P_SAMPLE304PLD_1|2017/01/27|4712/12/31|SSID1_P_SAMPLE304WRKR_1|US|M|M METADATA|WorkRelationship|SourceSystemOwner|SourceSystemId|PersonId(SourceSystemId)|LegalEmployerName|DateStart|WorkerType|PrimaryFlag MERGE|WorkRelationship|HCM_SAMPLE-001|SSID1_P_SAMPLE304WR_1|SSID1_P_SAMPLE304WRKR_1|Lastname-6-HX1|2017/01/27|E|Y METADATA|WorkTerms|SourceSystemOwner|SourceSystemId|PeriodOfServiceId(SourceSystemId)|ActionCode|EffectiveStartDate|EffectiveEndDate|EffectiveSequence|EffectiveLatestChange|AssignmentName|AssignmentNumber|PrimaryWorkTermsFlag MERGE|WorkTerms|HCM_SAMPLE-001|SSID1_P_SAMPLE304WT_1|SSID1_P_SAMPLE304WR_1|HIRE|2017/01/27|4712/12/31|1|Y|P_SAMPLE304_WTNM_1|P_SAMPLE304_WTNUM_1|Y METADATA|Assignment|SourceSystemOwner|SourceSystemId|ActionCode|EffectiveStartDate|EffectiveEndDate|EffectiveSequence|EffectiveLatestChange|WorkTermsAssignmentId(SourceSystemId)|AssignmentName|AssignmentNumber|AssignmentStatusTypeCode|PersonTypeCode|BusinessUnitShortCode|PrimaryAssignmentFlag MERGE|Assignment|HCM_SAMPLE-001|SSID1_P_SAMPLE304A_1|HIRE|2017/01/27|4712/12/31|1|Y|SSID1_P_SAMPLE304WT_1|P_SAMPLE304_AN_1|P_SAMPLE304_ANUM_1|ACTIVE_PROCESS|Employee|HDL_BU_SET1|Y METADATA|PersonUserInformation|PersonNumber|UserName|GeneratedUserAccountFlag|UsernameMatchingFlag MERGE|PersonUserInformation|P_SAMPLE304WRKR_1|Firstname.Lastname|Y|Y
In the file, we instruct HDL to link the person to an already existing user account that has been provisioned before. The actual linking is done by setting the UserNameMatchingFlag field to Y.
There are use cases that revoke a User Account from Fusion Applications Cloud for a defined time. Revoking a User Account just removes the User Account from Fusion Applications Cloud, the related Worker or Person structure will not be modified, i.e. all details and role assignements are still present. But it cannot be used by any user because the User Account is missing.
To relink an existing user account follow these steps:
User provisioning to Fusion Applications Cloud is a complex task and requires a thorough process planing to be done right. However, when this process is in place, it is very powerful and speeds up User onboarding and improves your business processes.