Oracle® Fusion
Applications Workforce Deployment Implementation Guide 11g Release 6 (11.1.6) Part Number E20379-06 |
![]() Home |
![]() Contents |
![]() Book List |
![]() Contact Us |
![]() Previous |
![]() Next |
This chapter contains the following:
Role Provisioning and Deprovisioning: Explained
Synchronization of User and Role Information with Oracle Identity Management: How It Is Processed
Defining Security After Enterprise Setup: Points to Consider
Defining Data Security After Enterprise Setup: Points to Consider
Securing Identities and Users: Points To Consider
Define Data Security for Human Capital Management
A user's access to data and functions depends on the user's roles: users have one or more roles that enable them to perform the tasks required by their jobs or positions. Roles must be provisioned to users; otherwise, users have no access to data or functions.
Roles can be provisioned to users:
Automatically
Manually, using delegated administration:
Users such as line managers and human resource specialists can provision roles manually to other users.
Users can request roles for themselves.
For both automatic and manual role provisioning, you create a role mapping to identify when a user becomes eligible for a role.
Oracle Identity Management (OIM) can be configured to notify users when their roles change; notifications are not issued by default.
Data roles, abstract roles, and job roles can be provisioned to users. Roles available for provisioning include predefined roles, HCM data roles, and roles created using OIM.
A role is provisioned to a user automatically when at least one of the user's assignments satisfies the conditions specified in the relevant role-mapping definition. The provisioning occurs when the assignment is either created or updated. For example, when a person is promoted to a management position, the line manager role is provisioned automatically to the person if an appropriate role mapping exists. Any change to a person's assignment causes the person's automatically provisioned roles to be reviewed and updated as necessary.
Automatically provisioned roles are deprovisioned automatically as soon as a user no longer satisfies the role-mapping conditions. For example, a line manager role that is provisioned to a user automatically is deprovisioned automatically when the user ceases to be a line manager.
Automatically provisioned roles can be deprovisioned manually at any time.
Manually provisioned roles are deprovisioned automatically only when all of the user's work relationships are terminated; in all other circumstances, users retain manually provisioned roles until they are deprovisioned manually.
When a person's line manager is changed, the roles of both new and previous line managers are updated as necessary. For example, if the person's new line manager now satisfies the conditions in the role mapping for the line manager role, and the role is one that is eligible for autoprovisioning, then that role is provisioned automatically to the new line manager. Similarly, if the previous line manager no longer satisfies the conditions for the line manager role, then that role is deprovisioned automatically.
When a work relationship is terminated, all automatically provisioned roles for which the user does not qualify in other work relationships are deprovisioned automatically. Manually provisioned roles are deprovisioned automatically only if the user has no other work relationships; otherwise, the user retains all manually provisioned roles until they are deprovisioned manually.
Automatic deprovisioning can occur either as soon as the termination is submitted or approved or on the day after the termination date. The user who is terminating the work relationship selects the appropriate deprovisioning date.
Role mappings can provision roles to users automatically at termination. For example, the locally defined roles Retiree and Beneficiary could be provisioned to users at termination based on assignment status and person type values.
If a termination is later reversed, roles that were deprovisioned automatically at termination are reinstated and post-termination roles are deprovisioned automatically.
Automatic role provisioning and deprovisioning are based on current data. For a future-dated transaction, such as a future promotion, role changes are identified and role provisioning occurs on the day the changes take effect, not when the change is entered. The process Send Pending LDAP Requests identifies future-dated transactions and manages role provisioning and deprovisioning at the appropriate time. Note that such role-provisioning changes are effective as of the system date; therefore, a delay of up to 24 hours may occur before users in other time zones acquire the access for which they now qualify.
User access to data and functions is determined by abstract, job, and data roles, which are provisioned to users either automatically or manually. To enable a role to be provisioned to users, you define a relationship, known as a mapping, between the role and a set of conditions, typically assignment attributes such as department, job, and system person type. In a role mapping, you can select any role stored in the Lightweight Directory Access Protocol (LDAP) directory, including Oracle Fusion Applications predefined roles, roles created in Oracle Identity Management (OIM), and HCM data roles.
The role mapping can support:
Automatic provisioning of roles to users
Manual provisioning of roles to users
Role requests from users
Immediate provisioning of roles
A role is provisioned to a user automatically if:
At least one of the user's assignments satisfies all conditions associated with the role in the role mapping.
You select the Autoprovision option for the role in the role mapping.
For example, for the HCM data role Sales Manager Finance Department, you could select the Autoprovision option and specify the following conditions.
Attribute |
Value |
---|---|
Department |
Finance Department |
Job |
Sales Manager |
Assignment Status |
Active |
The HCM data role Sales Manager Finance Department is provisioned automatically to users with at least one assignment that satisfies all of these conditions.
Automatic role provisioning occurs as soon as the user is confirmed to satisfy the role-mapping conditions, which can be when the user's assignment is either created or updated. The provisioning process also removes automatically provisioned roles from users who no longer satisfy the role-mapping conditions.
Note
The automatic provisioning of roles to users is effectively a request to OIM to provision the role. OIM may reject the request if it violates segregation-of-duties rules or fails a custom OIM approval process.
Users such as human resource (HR) specialists and line managers can provision roles manually to other users; you create a role mapping to identify roles that can be provisioned in this way.
Users can provision a role to other users if:
At least one of the assignments of the user who is provisioning the role (for example, the line manager) satisfies all conditions associated with the role mapping.
You select the Requestable option for the role in the role mapping.
For example, for the HCM data role Quality Assurance Team Leader, you could select the Requestable option and specify the following conditions.
Attribute |
Value |
---|---|
Manager with Reports |
Yes |
Assignment Status |
Active |
Any user with at least one assignment that satisfies both of these conditions can provision the role Quality Assurance Team Leader manually to other users, who are typically direct and indirect reports.
If the user's assignment subsequently changes, there is no automatic effect on roles provisioned by this user to others; they retain manually provisioned roles until either all of their work relationships are terminated or the roles are manually deprovisioned.
Users can request roles when reviewing their own account information; you create a role mapping to identify roles that users can request for themselves.
Users can request a role if:
At least one of their own assignments satisfies all conditions associated with the role mapping.
You select the Self-requestable option for the role in the role mapping.
For example, for the Expenses Reporting role you could select the Self-requestable option and specify the following conditions.
Attribute |
Value |
---|---|
Department |
ABC Department |
System Person Type |
Employee |
Assignment Status |
Active |
Any user with at least one assignment that satisfies all of these conditions can request the role. The user acquires the role either immediately or, if approval is required, once the request is approved. Self-requested roles are classified as manually provisioned.
If the user's assignment subsequently changes, there is no automatic effect on self-requested roles. Users retain manually provisioned roles until either all of their work relationships are terminated or the roles are manually deprovisioned.
When you create a role mapping, you can apply autoprovisioning from the role mapping itself.
In this case, all assignments and role mappings in the enterprise are reviewed. Roles are:
Provisioned immediately to all users who do not currently have roles for which they are eligible
Deprovisioned immediately from users who are no longer eligible for roles that they currently have
Immediate autoprovisioning from the role mapping enables bulk automatic provisioning of roles to a group of users who are identified by the role-mapping conditions. For example, if you create a new department after a merger, you can provision relevant roles to all users in the new department by applying autoprovisioning immediately.
To provision roles immediately to a single user, the user's line manager or an HR specialist can autoprovision roles from that user's account.
The names of role mappings must be unique in the enterprise. You are recommended to devise a naming scheme that reveals the scope of each role mapping. For example:
Name |
Description |
---|---|
Autoprovisioned Roles Sales Department |
Mapping includes all roles provisioned automatically to anyone in the sales department |
Benefits Specialist Autoprovisioned |
Mapping defines the conditions for autoprovisioning the Benefits Specialist role |
Line Manager Requestable Roles |
Mapping includes all roles that a line manager can provision manually to direct and indirect reports |
Roles must be provisioned to users explicitly, either automatically or manually; no role is provisioned to a user by default. This topic provides some examples of typical role mappings to support automatic and manual role provisioning.
You want all employees in your enterprise to have the Employee role automatically when they are hired. In addition, employees must be able to request the Expenses Reporting role when they need to claim expenses. Few employees will need this role, so you decide not to provision it automatically to all employees.
You create a role mapping called All Employees and enter the following conditions.
Attribute |
Value |
---|---|
System Person Type |
Employee |
Assignment Status |
Active |
In the role mapping you include the:
Employee role, and select the Autoprovision option
Expenses Reporting role, and select the Self-requestable option
You could create a similar role mapping for contingent workers called All Contingent Workers, where you would set the system person type to contingent worker.
Note
If the Employee and Contingent Worker roles are provisioned automatically, pending workers acquire them when their periods of employment or placements start. If they need roles before then, you create a separate role mapping for the pending worker system person type.
Any type of worker can be a line manager in the sales business unit. You create a role mapping called Line Manager Sales BU and enter the following conditions.
Attribute |
Value |
---|---|
Business Unit |
Sales |
Assignment Status |
Active |
Manager with Reports |
Yes |
You include the Line Manager role and select the Autoprovision option. This role mapping ensures that the Line Manager role is provisioned automatically to any worker with at least one assignment that matches the role-mapping conditions.
In the same role mapping, you could include roles that line managers in this business unit can provision manually to other users by selecting the roles and marking them as requestable. Similarly, if line managers can request roles for themselves, you could include those in the same role mapping and mark them as self-requestable.
Retirees in your enterprise need a limited amount of system access to manage their retirement accounts. You create a role mapping called All Retirees and enter the following conditions.
Attribute |
Value |
---|---|
System Person Type |
Retiree |
Assignment Status |
Inactive |
You include the locally defined role Retiree in the role mapping and select the Autoprovision option. When at least one of a worker's assignments satisfies the role-mapping conditions, the Retiree role is provisioned to that worker automatically.
Grade 6 sales managers in the sales department need the Sales Manager role. In addition, sales managers need to be able to provision the Sales Associate role to other workers. You create a role mapping called Sales Managers Sales Department and enter the following conditions.
Attribute |
Value |
---|---|
Department |
Sales |
Job |
Sales manager |
Grade |
6 |
Assignment Status |
Active |
In the role mapping, you include the:
Sales Manager role, and select the Autoprovision option
Sales Associate role, and select the Requestable option
Oracle Identity Management (OIM) maintains Lightweight Directory Access Protocol (LDAP) user accounts for users of Oracle Fusion Applications. OIM also stores the definitions of abstract, job, and data roles, and holds information about roles provisioned to users.
Most changes to user and role information are shared automatically and instantly by Oracle Fusion Human Capital Management (HCM) and OIM. In addition, two scheduled processes, Send Pending LDAP Requests and Retrieve Latest LDAP Changes, manage information exchange between Oracle Fusion HCM and OIM in some circumstances.
Send Pending LDAP Requests sends to OIM bulk requests and future-dated requests that are now active.
Retrieve Latest LDAP Changes requests from OIM changes that may not have arrived because of a failure or error, for example.
You are recommended to run the Send Pending LDAP Requests process at least daily to ensure that future-dated changes are identified and processed as soon as they take effect. Retrieve Latest LDAP Changes can also run daily, or less frequently if you prefer. For example, if you know that a failure has occurred between OIM and Oracle Fusion HCM, then you can run Retrieve Latest LDAP Changes to ensure that user and role information is synchronized.
When processing bulk requests, the batch size that you specify for the Send Pending LDAP Requests process is the number of requests to be processed in a single batch. For example, if 400 requests are to be processed and you specify a batch size of 25, then 16 batches of requests will be created and processed in parallel.
Synchronization of most user and role information between Oracle Fusion HCM and OIM occurs automatically. However, when you run Send Pending LDAP Requests to process future-dated or bulk requests, it sends to OIM:
Requests to create, suspend, and re-enable user accounts.
When a person record is created in Oracle Fusion HCM, OIM creates a user account automatically.
When all of a person's work relationships are terminated and the person has no roles, the person's user account is suspended automatically. If the person is subsequently rehired, the suspended account is automatically re-enabled.
Role provisioning and role deprovisioning changes for individual users.
Changes to relevant person attributes for individual users.
New and updated information about HCM data roles, which are created in Oracle Fusion HCM.
Note
It is possible to disable, for the enterprise, most default processing of Send Pending LDAP Requests. In particular, you can prevent the:
Default creation of user accounts
Automatic provisioning and deprovisioning of roles
Automatic sharing of changes to person attributes
To control the processing of Send Pending LDAP Requests, you perform the task Manage Enterprise HCM Information.
The process Retrieve Latest LDAP Changes sends to Oracle Fusion HCM:
Names of new user accounts.
When a person record is created in Oracle Fusion HCM, OIM creates a user account automatically and returns:
The user account name and password. If the user's primary work e-mail address was entered when the person record was created, then the user account name and password are returned to the user; otherwise, this information is returned to the primary work e-mail address of the user's line manager. (No notification is sent if the user has no line manager or the line manager has no primary work e-mail address.)
The globally unique identifier (GUID) associated with the LDAP directory user account, which is added automatically to the person record.
Latest information about abstract, job, and data roles.
OIM stores latest information about all abstract, job, and data roles, including HCM data roles. Oracle Fusion HCM maintains a local copy of all role names and types so that lists of roles presented in role mappings and elsewhere are up to date.
Note
New HCM data roles are available only when OIM has returned information about those roles to Oracle Fusion HCM.
Work e-mail addresses, if OIM owns the work e-mail address.
If automatic maintenance of user accounts is enabled for the enterprise (which it is by default), then the values of the following person attributes are sent to OIM automatically whenever a person record is created and whenever any of these attributes is subsequently updated.
Person number
System person type from the person's primary assignment
The GUID of the manager of the person's primary assignment
Work e-mail address, if Oracle Fusion HCM owns the work e-mail address
Work phone number
Work FAX number
Both local and global versions of the person's display name
Global versions of the following name components:
First name
Middle name
Last name
Name suffix
Both the formatted work-location address and the following components of the work-location address from the person's primary assignment:
Address line 1
City
State
Postal code
Country code
The person's preferred language
The person's user name, if this value itself has changed
Equivalent information for trading community parties is also shared with OIM.
No personally identifiable information (PII) is sent from Oracle Fusion HCM to OIM.
After the implementation user has set up the enterprise, further security administration depends on the requirements of your enterprise.
The Define Security activity within the Information Technology (IT) Management business process includes the following tasks.
Import Worker Users
Import Partner Users
Manage Job Roles
Manage Duties
Manage Application Access Controls
If no legacy users, user accounts, roles, and role memberships are available in the Lightweight Directory Access Protocol (LDAP) store, and no legacy workers are available in Human Resources (HR), the implementation user sets up new users and user accounts and provisions them with roles available in the Oracle Fusion Applications reference implementation.
If no legacy identities (workers, suppliers, customers) exist to represent people in your enterprise, implementation users can create new identities in Human Capital Management (HCM), Supplier Portal, and Customer Relationship Management (CRM) Self Service, respectively, and associate them with users.
Oracle Identity Management (OIM) handles importing users.
If legacy employees, contingent workers, and their assignments exist, the HCM Application Administrator imports these definitions by performing the Load Batch Data task. If user and role provisioning rules have been defined, the Load Batch Data process automatically creates user and role provisioning requests as the workers are created.
Once the enterprise is set up, performing the Load Batch Data task populates the enterprise with HR workers in records linked by global user ID (GUID) to corresponding user accounts in the LDAP store. If no user accounts exist in the LDAP store, the Load Batch Data task results in new user accounts being created. Worker email addresses as an alternate input for the Load Batch Data task triggers a search of the LDAP for user GUIDs, which may perform more slowly than entering user names.
In the security reference implementation, the HCM Application Administrator job role hierarchy includes the HCM Batch Data Loading Duty role, which is entitled to import worker identities. This entitlement provides the access necessary to perform the Load Batch Data task in HCM.
Note
The Import Person and Organization task in the Define Trading Community Import activity imports the following resources, creates users, and links the resources to users for use in CRM.
Internal employees
Contingent workers
External partner contacts
Partner companies
Legal entities
Customers
Consumers
If role provisioning rules have been defined, the Import Person and Organization task automatically provisions role requests as the users are created.
If legacy users (identities) and user accounts exist outside the LDAP store that is being used by the Oracle Fusion Applications installation, the IT security manager has the option to import these definitions to the LDAP store by performing the Import Worker Users and Import Partner Users tasks.
If no legacy users or user accounts can be imported or exist in an LDAP repository accessible to Oracle Identity Management (OIM), the IT security manager creates users manually in OIM or uses the Load Batch Data task to create users from imported HR workers.
Once users exist, their access to Oracle Fusion Applications is dependent on the roles provisioned to them in OIM or Human Capital Management. Use the Manage HCM Role Provisioning Rules task to define rules that determine what roles are provisioned to users.
Importing user identities from other applications, including other Oracle Applications product lines, is either a data migration or manual task. Migrating data from other Oracle Applications includes user data. For more information about importing users, see the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.
In the security reference implementation, the IT Security Manager job role hierarchy includes the HCM Batch Data Loading Duty and the Partner Account Administration Duty. These duty roles provide entitlement to import or create users. The entitlement Load Batch Data provides the access necessary to perform the Import Worker Users task in OIM. The entitlement Import Partner entitlement provides the access necessary to perform the Import Partner Users task in OIM.
Job and abstract roles are managed in OIM. This task includes creating and modifying job and abstract roles, but not managing role hierarchies of duties for the jobs.
Note
Manage Job Roles does not include provisioning job roles to users. Provisioning users is done in OIM, HCM, CRM or Oracle Fusion Supplier Portal.
Roles control access to application functions and data. Various types of roles identify the functions performed by users.
The Oracle Fusion Applications security reference implementation provides predefined job and abstract roles. In some cases, the jobs defined in your enterprise may differ from the predefined job roles in the security reference implementation. The predefined roles and role hierarchies in Oracle Fusion may require changes or your enterprise may require you to create new roles. For example, you need a job role for a petty cash administrator, in addition to an accounts payable manager. The security reference implementation includes a predefined Accounts Payable Manager, and you can create a petty cash administrator role to extend the reference implementation.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Enterprise Role Management Duty role, which is entitled to manage job and abstract roles (the entitlement is Manage Enterprise Role). This entitlement provides the access necessary to perform the Manage Job Roles task in OIM.
A person with a job role must be able to perform certain duties. In the Oracle Fusion Applications security reference implementation, enterprise roles inherit duties through a role hierarchy. Each duty corresponds to a duty role. Duty roles specify the duties performed within applications and define the function and data access granted to the enterprise roles that inherit the duty roles.
Managing duties includes assigning duties to job and abstract roles in a role hierarchy using Authorization Policy Manager (APM). If your enterprise needs users to perform some actions in applications coexistent with Oracle Fusion applications, you may wish to remove the duty roles that enable those actions. For details about which duty roles are specific to the products in an offering, see the Oracle Fusion Applications Security Reference Manual for each offering.
OIM stores the role hierarchy and the spanning of roles across multiple pillars or logical partitions of applications.
In cases where your enterprise needs to provide access to custom functions, it may be necessary to create or modify the duty roles of the reference implementation.
Tip
As a security guideline, use only the predefined duty roles, unless you have added new applications functions. The predefined duty roles fully represent the functions and data that must be accessed by application users and contain all appropriate entitlement. The predefined duty roles are inherently without segregation of duty violations of the constraints used by the Application Access Controls Governor.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Application Role Management Duty role, which is entitled to manage duty roles (the entitlement is Manage Application Role). This entitlement provides the access necessary to perform the Manage Duties task in APM.
Note
Product family administrators are not entitled to create role hierarchies or manage duty roles and must work with the IT security manager to make changes such as localizing a duty role to change a role hierarchy. Setup for localizations is documented in HCM documentation.
Prevent or limit the business activities that a single person may initiate or validate by managing segregation of duties policies in the Application Access Controls Governor (AACG) .
Note
In AACG, segregation of duties policies are called access controls or segregation of duties controls.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Segregation of Duties Policy Management Duty role, which is entitled to manage segregation of duties policies (the entitlement is Manage Segregation of Duties Policy). This entitlement provides the access necessary to perform the Manage Application Access Controls task in AACG.
After the implementation user has set up the enterprise, further security administration depends on the requirements of your enterprise.
The Define Data Security activity within the Information Technology (IT) Management business process includes the following tasks.
Manage Data Access Sets
Manage Segment Security
Manage Role Templates
Manage Data Security Policies
Manage Encryption Keys
These tasks address data security administration. For information on using the user interface pages for setting up and managing data security, see the Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager (Oracle Fusion Applications edition).
Note
The Manage Data Role and Security Profiles task, and all other HCM security profile setup tasks are documented in Human Capital Management (HCM) documentation.
Data access sets define a set of access privileges to one or more ledgers or ledger sets.
The information on ledgers that are attached to data access sets are secured by function security. Users must have access to the segment values associated with the data access sets to access the corresponding GL account.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Data Access Administration Duty role, which is entitled to manage data access sets (the entitlement is Define General Ledger Data Access Set). This entitlement provides the access necessary to perform the Manage Data Access Sets task in General Ledger.
Balancing or management segment values can secure data within a ledger.
Segment values are stored in GL_ACCESS_SET_ASSIGNMENTS and secured by restrictions, such as Exclude, on parameters that control the set of values that a user can use during data entry.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Application Key Flexfield Administration Duty role, which is entitled to manage application key flexfields (the entitlement is Manage Application Key Flexfield). This entitlement provides the access necessary to perform the Manage Segment Security task in General Ledger.
Data role templates automatically create or update data roles based on dimensions such as business unit. As an enterprise expands, data role templates trigger replication of roles for added dimensions. For example, when creating a new business unit, a data role template generates a new Accounts Payables Manager data role based on the Financials Common Module Template for Business Unit Security data role template.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Application Role Management Duty role, which is entitled to manage data role templates (the entitlement is Manage Role Template). This entitlement provides the access necessary to perform the Manage Role Templates task in APM.
Data security grants provisioned to roles are data security policies. The security reference implementation provides a comprehensive set of predefined data security policies and predetermined data security policies based on data role templates.
Data security policies are available for review in Authorization Policy Manager (APM). Data security policies are implemented by grants stored in Oracle Fusion Data Security (FND_GRANTS).
Data security policies secure the database resources of an enterprise. Database resources are predefined applications data objects and should not be changed. However, for cases where custom database resources must be secured objects, the IT security manager is entitled to manage database resources and create new data security policies.
Warning
Review but do not modify HCM data security policies in APM except as a custom implementation. Use the HCM Manage Data Role And Security Profiles task to generate the necessary data security policies and data roles.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Application Role Management Duty role, which is entitled to manage data security policies (the entitlement is Manage Data Security Policy). This entitlement provides the access necessary to perform the Manage Data Security Policies task in APM.
Create or edit encryption keys held in Oracle Wallet to secure Personally Identifiable Information (PII) attributes This task is only available when Payments is implemented.
In the security reference implementation, the IT Security Manager job role hierarchy includes the Payments Data Security Administration Duty role, which is entitled to manage encryption keys that secure PII (the entitlement is Manage Wallet). This entitlement provides the access necessary to perform the Manage Encryptions Keys task in Payments.
Identity covers all aspects of an entity's existence within the contexts in which it is used. The identity of an enterprise user consists of HR attributes, roles, resources, and relationships.
HR attributes include identifying information about a user that is relatively static and well understood, such as first and last name, title, and job function.
Roles are part of a user's identity and define the user's purpose and responsibilities.
Within identity management, resources define what a user can and does do. In an enterprise, this typically translates into what resources a user has access to, what privileges they have on that resource, and what they have been doing on that resource. Resources can be application accounts or physical devices such as laptops or access cards. The enterprise owns the resources, secures them, and manages access to the resources by managing the user's identity and access.
Relationships establish the portion of user identities that involve organizational transactions such as approvals.
An Oracle Fusion Applications user and corresponding identity are usually created in a single transaction, such as when a worker is created in Human Resources (HR). That transaction automatically triggers provisioning requests for the user based on role provisioning rules.
User accounts for some identities that are not employees, such as partner contacts, may be created in a later transaction using an identity that is already created in the identity store. Supplier contacts are created in the Supplier Model, not HR.
Various locations store identity and user data.
Identity data consists of the following.
HR person records
Oracle Fusion Trading Community Model party records
In Oracle Fusion Applications, identities and users correspond one to one, but not all identities correspond to a user, and not all users are provisioned with an identity. Some identities stored in HR and Trading Community Model may not be provisioned to user accounts and therefore are not synchronized with Oracle Identity Management (OIM). For example, a contact for a prospective customer is an identity in Trading Community Model but may not be provisioned with a user account in OIM. Some users stored in the Lightweight Directory Access Protocol (LDAP) store may not be provisioned with identities. For example, system user accounts used to run Web services to integrate third party services with Oracle Fusion Applications are not associated with a person record in HR or Trading Community Model. Some identifying credentials such as name, department, e-mail address, manager, and location are stored with user data in the LDAP store.
You can import users or user attributes in bulk from existing legacy identity and user stores.
Your tasks may include the following.
Create users in bulk
Update specific attributes for all users, such as postal code
Link users to HR or Trading Community Model persons
Monitor progress of the import process
Correct errors & re-import
Export users in bulk
Import and export users using a standard plain text data interchange format like Lightweight Data Interchange Format (LDIF)
You can reserve a specific user name not currently in use for use in the future, or release a reserved username from the reservation list and make it available for use. Between a user registration request and approved registration, Oracle Fusion Applications holds the requested user name on the reservation list, and releases the name if an error occurs in the self-registration process or the request is rejected. Self-registration processes check the reservation list for user name availability and suggest alternative names.
New identities, such as new hires, trigger user and role provisioning events. In addition to user creation tasks, other tasks, such as Promote Worker or Transfer Worker, result in role provisioning and recalculation based on role provisioning rules.
When an identity's attributes change, you may need to provision the user with different roles. Role assignments may be based on job codes, and a promotion triggers role provisioning changes. Even if the change in the identities attributes requires no role assignment change, such as with a name change, OIM synchronizes the corresponding user information in the LDAP store.
Deactivating or terminating an identity triggers revocation of some roles to end all assignments, but may provision new roles needed for activities, such as a pay stub review. If the corresponding user for the identity was provisioned with a buyer role, terminating the identity causes the user's buyer record in Procurement to be disabled, just as the record was created when the user was first provisioned with the buyer role.
Oracle Fusion Applications provides mechanisms for notifying and auditing requests or changes affecting identities and users.
Oracle Fusion Applications notifies requestors, approvers, and beneficiaries when a user account or role is provisioned. For example, when an anonymous user registers as a business-to-customer (B2C) user, the B2C user must be notified of the registration activation steps, user account, password and so on once the approver (if applicable) has approved the request and the user is registered in the system.
User ID and GUID attributes are available in Oracle Fusion Applications session information for retrieving authenticated user and identity data.
End user auditing data is stored in database WHO columns and used for the following activities.
Setting up sign-in audit
Using the application monitor
Notifying of unsuccessful sign ins
Sign-in audit reports
You can conduct real time audits that instantiate a runtime session and impersonate the target user (with the proxy feature) to test what a user has access to under various conditions such as inside or outside firewall and authentication level.
For information on configuring audit policies and the audit store, see the Oracle Fusion Applications Administrator's Guide.
You can designate local administrators as delegated administrators to manage a subset of users and roles.
Delegated administrators can be internal or external persons who are provisioned with a role that authorizes them to handle provisioning events for a subset of users and roles.
For example, internal delegated administrators could be designated to manage users and roles at the division or department level. External delegated administrators could be designated to manage users and roles in an external organization such as a primary supplier contact managing secondary users within that supplier organization.
You can also define delegated administration policies based on roles. You authorize users provisioned with specific roles named in the policy to request a subset of roles for themselves if needed, such as authorizing a subset of roles for a subset of people. For example, the policy permits a manager of an Accounts Payables department to approve a check run administrator role for one of their subordinates, but prohibits the delegated administrator from provisioning a budget approver role to the subordinate.
You activate or change credentials on users by managing them in Oracle Identity Management (OIM)
Applications themselves must be credentialed to access one another.
Oracle Fusion Applications distinguishes between user identities and application identities (APPID). Predefined application identities serve to authorize jobs and transactions that require higher privileges than users.
For example, a payroll manager may submit a payroll run. The payroll application may need access to the employee's taxpayer ID to print the payslip. However, the payroll manager is not authorized to view taxpayer IDs in the user interface as they are considered personally identifiable information (PII).
Calling applications use application identities (APPID) to enable the flow of transaction control as it moves across trust boundaries. For example, a user in the Distributed Order Orchestration product may release an order for shipping. The code that runs the Pick Notes is in a different policy store than the code that releases the product for shipment. When the pick note printing program is invoked it is the Oracle Fusion Distributed Order Orchestration Application Development Framework (ADF) that is invoking the program and not the end user.
HCM data roles, like all Oracle Fusion Applications data roles, define data security policies: they enable users to perform a set of tasks, using identified menus, menu items, and pages in application user interfaces, on a specified set of data within those user interfaces. Because data roles are specific to the enterprise, no predefined HCM data roles exist.
HCM data roles differ from other data roles in the following ways:
You create and maintain HCM data roles outside Oracle Identity Management (OIM) and the Oracle Fusion Middleware Authorization Policy Manager (APM), and they are not based on data role templates.
Although HCM data roles are visible in the Oracle Fusion Middleware APM, they must not be maintained there.
A single HCM data role can enable access to data of multiple types.
You identify the data that users can access in HCM security profiles. You can create security profiles for the person, organization, position, country, legislative data group (LDG), document type, payroll, payroll flow, and workforce business process objects.
Each HCM data role is associated with a single job role, which you select from the list of enterprise roles. The HCM securing objects that the selected role needs to access are identified automatically, and the appropriate types of security profile are displayed. For example, if you select the job role human resource analyst, users with that job role need to access managed person, public person, organization, position, LDG, and document type data; therefore, security profiles for those object types must be included in the HCM data role. The security profile types that appear in the HCM data role vary according to the data requirements of the selected job role.
If you select a job role that requires no access to HCM data secured by security profiles, you cannot create an HCM data role.
Note
If you create custom job roles in OIM, you must add them to a locally defined role category that ends with "Job Roles"; otherwise, they do not appear in the list of job roles when you create an HCM data role. Do not add custom job roles to the predefined role category HCM - Job Roles.
You can either create new security profiles or use existing security profiles. For each object type, you can include only one security profile in an HCM data role.
When users have multiple HCM data roles, the data security policies arising from each role remain separate. For example, being able to promote or terminate workers in the purchasing department in one HCM data role and view contact details of all workers in the sales department in another HCM data role does not enable a user to promote or terminate workers in the sales department.
The following figure summarizes how the components of the HCM data role contribute to Oracle Fusion Data Security for the data role. Oracle Fusion Data Security comprises the data security policies for data roles that are generated automatically when data roles are created.
The job role that you select in the HCM data role inherits multiple duty roles. Each duty role has one or more function privileges and related data privileges, from which the relevant HCM objects are identified. The specific instances of the objects required by this HCM data role are identified in security profiles and stored in a data instance set. Data security policy data is created automatically in Oracle Fusion Data Security when you create the data role.
For example, the human resource specialist job role inherits the employee hire and worker promotion duty roles, among many others. The inherited duty roles provide both function privileges, such as Hire Employee, Rehire Employee, and Promote Workers, and data privileges to HCM objects, such as person and assignment. The specific instances of those objects required by this HCM data role, such as people with assignments in a specified legal employer and department, are identified in security profiles.
Human capital management (HCM) objects to which access is secured by HCM data roles are identified as either securing objects or secured objects.
The person, organization, position, country, legislative data group (LDG), document type, payroll, payroll flow, and workforce business process objects are referred to as HCM securing objects. An HCM securing object secures access to both its own data and data in child or related objects. For example, access to a specified organization can also allow access to associated model profiles. Instances of HCM securing objects that users can access are identified in security profiles. The type of security profile that you use to identify instances of an HCM securing object is fixed; for example, you identify person records in a person security profile and position records in a position security profile.
Whether a particular user can access all of the secured data in practice is controlled by data security policies: for example, a compensation manager may be able to enter salary details for a specified set of person records, while a benefits manager may be able only to view salary details in the same set of person records.
An HCM secured object is a business object to which access is controlled by its relationship with a securing object. For example, salary details are secured objects that are secured by the person securing object.
Securing objects can also be secured objects. For example, access to person records can be controlled by person data, such as person type or name range, or by other securing objects, such as organization or position, or both.
A security profile defines the criteria that identify instances of a human capital management (HCM) object. For example, a person security profile defines the criteria that identify one or more person records, and a position security profile defines the criteria that identify one or more positions. When you include a security profile in an HCM data role and provision the data role to a user, that user can access the data instances identified in the security profile. The type of access available to the user (for example whether the user can edit or simply view the data) depends on the job role identified in the HCM data role.
You can create security profiles for the following HCM object types:
Person
Managed person
Public person
Organization
Position
Legislative data group (LDG)
Country
Document type
Payroll
Payroll flow
Workforce business process
All security profile definitions for these HCM objects are eventually visible in the Oracle Fusion Middleware Authorization Policy Manager (APM). The name of the security profile's data instance set in the Oracle Fusion Middleware APM is derived from the name of the security profile and the relevant object type. For example, if the security profile name is Manager Hierarchy, then the data instance set for the object PER_ALL_PEOPLE_F is HCM:PER:PER_ALL_PEOPLE_F:Manager Hierarchy.
You must use the Oracle Fusion Human Capital Management interfaces, which are designed for ease of use and access, to create and maintain security profiles; do not use the Oracle Fusion Middleware APM to maintain security profiles for these HCM objects.
In any HCM security profile, you specify the criteria that identify data instances of the relevant type. For example, in an organization security profile, you can identify organizations by organization hierarchy, by organization classification, or by listing organizations to include in or exclude from the security profile. All of the criteria in an HCM security profile apply when the data instance set is defined; for example, if you identify organizations by both organization hierarchy and organization classification, then both sets of criteria apply, and only those organizations that satisfy all criteria belong to the data instance set.
The following HCM security profiles are predefined:
Security Profile Name |
HCM Security Profile Type |
Description |
---|---|---|
View All People |
Person |
Identifies all person records in the enterprise |
View Own Record |
Person |
Identifies the signed-on user's own person record and the person records of that user's contacts |
View Manager Hierarchy |
Person |
Identifies the signed-on user's line manager hierarchy |
View All Workers |
Person |
Identifies the person records of all people who have a work relationship in the enterprise |
View All Organizations |
Organization |
Identifies all organizations in the enterprise |
View All Positions |
Position |
Identifies all positions in the enterprise |
View All Legislative Data Groups |
LDG |
Identifies all LDGs in the enterprise |
View All Countries |
Country |
Identifies all countries in the FND_TERRITORIES table |
View All Document Types |
Document Type |
Identifies all document types in the enterprise |
View All Payrolls |
Payroll |
Identifies all payrolls in the enterprise |
View All Flows |
Payroll Flow |
Identifies all payroll flows in the enterprise |
View All Workforce Business Processes |
Workforce Business Process |
Identifies all registered workforce business processes in the enterprise |
You can include the predefined security profiles in any HCM data role, but you cannot edit them. Note also that the View all option is disabled in any security profile that you create; this restriction exists because predefined security profiles exist for this requirement.
You can create security profiles either individually or as part of the process of creating an HCM data role. If you have standard requirements, it may be more efficient to create the security profiles individually and include them in appropriate HCM data roles.
Regardless of how you create them, all security profiles are reusable; they do not belong to particular HCM data roles, and you can include them in any HCM data role for which they define an appropriate data instance set.
You can include security profiles in other security profiles. For example, you can include an organization security profile:
In a person security profile, to secure person records by department, business unit, or legal employer
In a position security profile, to secure positions by department or business unit
Therefore, one security profile can inherit the data instance set defined by another.
Planning your use of HCM data roles and security profiles before you start creating them will enable you to minimize maintenance and ease the introduction of HCM data roles and security profiles in your enterprise.
In any enterprise, standard requirements for data access are likely to exist. For example, multiple HCM data roles may need access to all person records in a specific legal employer. If you create a person security profile that includes all person records in that legal employer, then you can include the security profile in as many HCM data roles as necessary. This approach simplifies the management of HCM data roles and security profiles, and may also prevent duplicate security profiles being created unnecessarily.
You are recommended to define and use a naming scheme for HCM data roles and security profiles.
Ideally, a security profile name identifies clearly the scope of the resulting data instance set so that, when creating or updating an HCM data role, users can confidently select an appropriate HCM security profile. For example, the person security profile name All Employees Sales Department conveys clearly that the security profile identifies all employees in the sales department.
The name of an HCM data role usefully includes both the name of the inherited job role and the data role scope. For example, the HCM data role Human Resource Analyst Finance Division identifies both the job role and the organization within which the role operates. HCM data role names must be less than 55 characters.
An HCM data role can include only one security profile of each type. For example, you can include one organization security profile, one managed person security profile, and one public person security profile. Therefore, you must plan the data-access requirements of any HCM data role to ensure that each security profile identifies all required data instances. For example, if a user needs to select legal employers, business units, and departments, then organizations of all three types must be identified by the organization security profile that you include in the HCM data role.
To provide access to all instances of an HCM object, use the appropriate predefined security profile. For example, to provide access to all person records in the enterprise, use the predefined security profile View All People.
An organization security profile identifies organizations by at least one of organization hierarchy, organization classification, and organization list.
These examples show some typical requirements for organization security profiles.
The HR IT administrator maintains the definitions of all types of organizations for the enterprise. You want the HR IT administrator's access to reflect any changes to the hierarchy without needing to update the security profile. Therefore, you:
Secure by organization hierarchy.
Select a generic organization hierarchy, so that the security profile data instance set includes organizations of all classifications.
Identify by name the top organization in the hierarchy that will be included in the data instance set of organizations. The HR IT administrator's needs are fixed; therefore, the top organization is unlikely to vary with the user's assignment.
If you secured by organization classification, you would need to update the security profile if organizations of different classifications were added to the user's responsibilities. Similarly, if you listed organizations to include in or exclude from the instance set, you would need to maintain the list as the enterprise's organization hierarchy evolved.
The human resource (HR) specialist needs access to lists of legal employers, business units, departments, reporting establishments, and disability organizations while creating and updating person records and assignments. To identify the organizations that the user can see in such lists, you:
Secure by organization hierarchy.
Select a generic organization hierarchy, because the HR specialist needs access to more than one type of organization.
Allow the top organization in the hierarchy to be the department from the user's assignment. This selection allows you to provision the HCM data role in which this organization security profile is included to multiple HR specialists who may be employed in different parts of the enterprise.
If the generic hierarchy contains organizations of types that the HR specialist does not need to access, you can additionally identify the classifications to be included. If additional organizations of the included classifications are later added to the hierarchy, you do not need to update the security profile. You would need to update the security profile only if the user became responsible for organizations of other classifications in the same HCM data role.
The HR specialist also needs access to person records, and one of the ways in which those records can be secured is by organization. If the set of organizations is the same, you can reuse this organization security profile to secure the person records in a person security profile.
A person security profile identifies person and assignment records by at least one of the following types of criteria: person type, manager hierarchy, workforce structure, global name range, and custom criteria.
These examples show typical requirements for person security profiles.
Human resource (HR) specialists for the ABC legal employer need access to the person and assignment records of anyone who has a work relationship with the legal employer. You create a person security profile named All ABC Workers. In the security profile, you:
Secure by person type and select the system person types employee, contingent worker, nonworker, and pending worker.
Set the access level to restricted for the selected person types.
Secure by legal employer, and select an existing organization security profile that identifies legal employer ABC and any subordinate organizations. The person security profile All ABC Workers inherits the organization security profile's data instance set.
The data instance set from the person security profile All ABC Workers comprises all employees, contingent workers, nonworkers, and pending workers in legal employer ABC.
Note
The data instance set from a person security profile also includes any person who has shared his or her information with the signed-on user. The only exception to this rule occurs for person security profiles in which Access to Own Record is the only security criterion.
If you do not:
Secure by person type, then the data instance set includes all person types, including those without work relationships, such as emergency contacts
Set the access level for these person types to restricted, then other criteria in the security profile are ignored; therefore, the data instance set includes all workers in the enterprise rather than in legal employer ABC
As you set the access level separately for each person type, you could set it to restricted for some person types and unrestricted for others. The other criteria in the security profile would apply only to the person types with restricted access.
You can include the security profile All ABC Workers in an HCM data role and provision the data role to any HR specialist in legal employer ABC.
You want to enable line managers in your enterprise to access the person and assignment records of people who report to them directly from at least one assignment. You also want line managers to have access to the person and assignment records of people who report to the assignments that they manage directly. Your management hierarchy comprises eight management levels, and you want to limit the number of levels of the hierarchy that each manager can access.
You create a person security profile named Line Manager Three Levels. In the security profile, you:
Secure by manager hierarchy, and set the Person or Assignment Level option to Assignment.
Set Maximum Levels in Hierarchy to 3, to ensure that the data instance set for any line manager comprises no more than 3 levels of the manager hierarchy.
Set Manager Type to Line Manager.
You can include this security profile in an HCM data role and provision that data role to any line manager in the enterprise.
Payroll administrators in Ireland need to be able to access the person and assignment records of employees. In Ireland, your enterprise has a large number of employees and several payroll administrators. You decide that some payroll administrators will manage the records of people whose names are in the range A through M and some will manage those in the range N through Z. Therefore, you create two person security profiles, Ireland Employees A to M and Ireland Employees N to Z.
In both security profiles, you
Secure by person type, select the employee system person type, and set the access level to restricted.
Secure by legal employer and select an existing organization security profile that identifies legal employers in Ireland.
In the person security profile Ireland Employees A to M, you secure by global name range and set the range to A through M.
In the person security profile Ireland Employees N to Z, you secure by global name range and set the range to N through Z.
You include each person security profile in a separate HCM data role, which you provision to appropriate payroll administrators. If necessary, you can provision both HCM data roles to a single payroll administrator. In this case, the payroll administrator would have access to employees in Ireland whose names are in the range A through Z.
Some users need to maintain position definitions for part or all of the enterprise. Other users need to access lists of positions when creating user assignments, for example. The users' access requirements vary, but in both cases you identify the positions that users can access in a position security profile.
These scenarios show typical uses of position security profiles.
The human resource (HR) specialist creates and maintains position definitions for the enterprise, with a few exceptions. To identify the set of positions that HR specialists can manage, you:
Secure by position hierarchy, select the enterprise position hierarchy tree, and identify the top position for which the HR specialist is responsible. You include the top position in the hierarchy.
Secure by position list, and identify by name the few positions for which the HR specialist is not responsible. You exclude these positions from the position security profile data instance set.
You can include this security profile in the relevant HCM data role and provision it to any HR specialist in the enterprise who has responsibility for these position definitions.
Line managers in your business unit can hire employees or add contingent workers when the positions of those new workers are below the managers' own positions in the position hierarchy. To identify the set of positions that line managers can allocate to new workers, you secure by position hierarchy, select the relevant position tree, and use the position from the user's assignment as the top position. You do not include the top position in the hierarchy.
You can include this position security profile in the relevant HCM data role and provision it to any line manager in your business unit.
Some senior managers in your enterprise can access the person records of workers who occupy positions below them in the position hierarchy; therefore, you secure access to those person records by position in the person security profile. To identify the relevant positions, you create a position security profile in which you secure by position hierarchy, identify the senior manager position as the top position, and do not include it in the hierarchy. This selection ensures that senior managers do not have access to the person records of other senior managers.
Some users need to manage document types for the enterprise. Others need to be able to manage the documents associated with the person records to which they have access. For example, workers need to be able to manage their own documents. The users' access requirements vary, but in both cases you identify the document types that users can access in a document type security profile.
Note
Document type security profiles secure access to locally defined document types only. They do not secure access to standard predefined document types, such as visas, work permits, and driver's licenses. Access to person records provides access to the standard predefined document types.
These scenarios show typical uses of document type security profiles.
Workers can manage their own documents from their portraits. If you create an HCM data role for a worker's job role, for example, you can include the predefined document type security profile View All Document Types, which includes all locally defined document types. Alternatively, you can create a document type security profile that includes specified document types only. In the document type security profile, you list document types either to include in the profile or to exclude from it. For example, if you have defined the document type Medical Record that you want only human resource (HR) specialists to manage, you could create a document type security profile for workers that excludes medical records. Workers would continue to have access to all other document types in the enterprise.
HR specialists who are responsible for managing the enterprise document types need to access all document types. You can provide this access by including the predefined document type security profile View All Document Types in the HCM data role that you provision to HR specialists who have this responsibility. This security profile also ensures that HR specialists can view and update all document information in the person records that they manage.
Some users maintain organization definitions for part or all of the enterprise, and some users need to access lists of organizations while performing other tasks, such as creating assignments. While the access requirements in each case are very different (and depend on the job role inherited by the user's HCM data role) for both types of user you identify relevant organizations in an organization security profile.
Organizations may have more than one classification. For example, a department may also be classified as a legal employer. An organization is included in an organization security profile data instance set if it satisfies any one of the security profile's classification criteria. For example, if you secure by department hierarchy only, a department that is also a legal employer appears in the organization security profile data instance set because it is a department. However, users of this organization security profile will not be able to access the organization as a legal employer.
If you select a named organization as the top organization in an organization hierarchy, you must ensure that the organization is and remains valid. No validation of the selection occurs, because changes to the organization hierarchy occur independently of the organization security profile.
When you select the department from the user's assignment as the top organization in an organization hierarchy, multiple top organizations may exist when the user has multiple assignments. In this case, all organizations from the relevant subhierarchies of the selected organization hierarchy belong to the organization security profile data instance set.
The following figure illustrates the effects of this option when the user has multiple assignments.
The user has two assignments, one in organization B and one in organization D, which belong to the same organization hierarchy. The top organizations are organizations B and D, and the user's data instance set of organizations therefore includes organizations B, E, D, F, and G.
You can secure person records by person type, manager
hierarchy, workforce structures, and global name range. You can also
specify custom criteria, in the form of SQL statements, in addition
to or in place of the standard criteria. The custom criteria can include
any statement where the predicate restricts by PERSON_ID or ASSIGNMENT_ID:
the custom predicate must include either &TABLE_ALIAS.PERSON_ID
or &TABLE_ALIAS.ASSIGNMENT_ID
as
a restricting column in the custom criteria.
The following scenario illustrates how to use custom criteria in a person security profile.
The person security profile data instance set must include employees in a single legal employer who were born before 01 January, 1990. You secure person records by:
Person type, where you select the employee system person type and set the access level to restricted
Legal employer, where you select an organization security profile that identifies the relevant legal employer and its subordinate organizations
You also secure by custom criteria, and enter the following statement:
&TABLE_ALIAS.PERSON_ID IN (SELECT PERSON_ID FROM PER_PERSONS
WHERE DATE_OF_BIRTH < TO_DATE('01-JAN-1990', 'DD-MON-YYYY'))
When you identify a set of person records by manager hierarchy, the person records that occur in the data instance set for the signed-on manager depend on how you specify the manager hierarchy in the person security profile.
You can select one of:
Person-level manager hierarchy
Assignment-level manager hierarchy
In both cases, the selection controls access to person records. Having access to a person's record enables the manager to access all of the person's assignments: you cannot enable the manager to access particular assignments.
Note
Managers other than line managers can access person records secured by manager hierarchy only if their roles have the appropriate function- and data-security access. Providing this access to managers other than line managers is a security-setup task.
Consider the following example manager hierarchy.
Harry is a line manager with two assignments. In his primary assignment, he manages Sven's primary assignment. In his assignment 2, Harry manages Jane's primary assignment. Monica is a line manager with one assignment. She manages Jane's assignment 2 and Amir's primary assignment. In her primary assignment, Jane manages Franco's primary assignment. In her assignment 2, Jane manages Kyle's primary assignment.
In a person-level manager hierarchy, the data instance set includes the person records of any person who is in a reporting line, directly or indirectly, to any of the signed-on manager's own assignments.
In a person-level manager hierarchy, Harry's data instance set includes the person records for Sven, Jane, Franco, and Kyle.
In a person-level manager hierarchy, Monica's data instance set includes the person records for Jane, Franco, Kyle, and Amir.
In a person-level manager hierarchy, Jane's data instance set includes the person records for Franco and Kyle.
When you include the person security profile in an HCM data role and assign the data role to a manager, the person-level hierarchy ensures that the signed-on manager can access the person record and all assignment records of every person in his or her manager hierarchy (subject to any other criteria in the security profile).
In an assignment-level manager hierarchy, managers see the person records of:
People who report to them directly from one or more assignments
People who report to the assignments that they manage
In an assignment-level manager hierarchy, Harry's data instance set includes Sven, Jane, and Franco. It does not include Kyle, because Kyle reports to an assignment that Monica manages.
In an assignment-level manager hierarchy, Monica's data instance set includes Jane, Kyle, and Amir. It does not include Franco, because Franco reports to an assignment that Harry manages.
In an assignment-level manager hierarchy, Jane's data instance set includes Franco and Kyle.
An assignment-level manager hierarchy is not the same as assignment-level security, which would secure access to individual assignments: you cannot secure access to individual assignments.
When you secure person records by manager hierarchy, the data instance set comprises person records from manager hierarchies of the specified types.
If you set Manager Type to:
All, the security profile includes all types of manager hierarchies
Line Manager, the security profile includes only the line manager hierarchy
Selected, the security profile includes only the specified type of manager hierarchy
Typically, you select Line Manager to identify the data instance set for line managers, Project Manager to identify the data instance set for project managers, and so on. If you select All, then users with the line manager job role (for example) will have line-manager access to person records in all of their manager hierarchies, which may not be what is required.
Manager job roles other than line manager are not predefined. Creating job roles for managers such as project managers and resource managers is a security-customization task. Once those roles exist, you can assign security profiles to them (either directly or by creating a separate HCM data role) to enable users with those roles to access their manager hierarchies in the Manager Resources Dashboard and elsewhere.
In a person security profile, you can identify a set of person records by one or more of the department, business unit, legal employer, position, payroll, and legislative data group (LDG) workforce structures. For example, the data instance set from a person security profile could include all workers who occupy a particular position at a specified legal employer.
You identify each of the work structures using a security profile of the relevant type.
To identify:
Departments, business units, and legal employers, you use organization security profiles
Positions, you use a position security profile
LDGs, you use an LDG security profile
Payrolls, you use a payroll security profile
These security profiles are reusable: you can include them in any person security profile where they can identify the relevant data instance set of person records. The person security profile inherits the data instance set of any security profile that you include.
Although the department, business unit, payroll, and position values are assignment attributes, you cannot secure access to individual assignments. Therefore, if one of a person's assignments satisfies the criteria in a person security profile, then all of the person's assignments belong to the person security profile's data instance set.
When you secure person records by LDG, a person's record and all assignments belong to the person security profile's data instance set if the LDG is associated with the payroll statutory unit of the person's legal employer.
When you secure person records by payroll, a person's record and all assignments belong to the person security profile's data instance set if at least one of the person's assignments includes the payroll.
If you secure person records by legal employer, then the person records and all assignments of workers with at least one work relationship of any type with the specified legal employer belong to the person security profile's data instance set. For such workers, assignments belonging to work relationships with other legal employers also belong to the data instance set.
Other criteria in the person security profile may limit the effects of securing by legal employer. For example, if you also secure person records by person type, select the employee system person type, and specify restricted access, then only persons who have employee work relationships with the specified legal employer belong to the security profile's data instance set. All other person records are excluded.
This example shows how to create an HCM data role.
The legal employer ABC Industrial comprises sales, development, and manufacturing departments. This example shows how to create an HCM data role for a human resource (HR) specialist in the sales department of ABC Industrial that will secure access to person and assignment records, organizations, positions, countries, legislative data groups (LDGs), document types, payrolls, and payroll flows.
The following table summarizes key decisions for this scenario.
Decisions to Consider |
In This Example |
---|---|
What is the name of the HCM data role? |
HR Specialist ABC Industrial - Sales Department |
Which job role will the HCM data role include? |
Human Resource Specialist |
Which person records do users need to access? |
Users need to access the managed person records of:
|
Which public person records do users need to access? |
All |
Which organizations do users need to access? |
All organizations of all types in ABC Industrial |
Which positions do users need to access? |
Vice President of Sales and all subordinate positions in the position hierarchy of ABC Industrial |
Which countries do users need to see in lists of countries? |
All |
Which LDGs do users need to access? |
The LDG for the legal employer ABC Industrial. This LDG is identified in an existing LDG security profile. |
Which document types do users need to access? |
All |
Which payrolls do users need to access? |
Payrolls for the legal employer ABC Industrial. These payrolls are identified in an existing payroll security profile. |
Which payroll flows do users need to access? |
Payroll flows for the legal employer ABC Industrial. These payroll flows are identified in an existing payroll flow security profile. |
Create the HCM data role by:
Naming the HCM data role and selecting the associated job role
Specifying the security criteria for each HCM object type
Creating new security profiles
Reviewing and submitting the new HCM data role
Field |
Value |
---|---|
Data Role |
HR Specialist ABC Industrial - Sales Department |
Job Role |
Human Resource Specialist |
Field |
Value |
---|---|
Organization Security Profile |
Create New |
Name |
ABC Industrial - All Organizations |
Secure by organization hierarchy |
Yes |
Field |
Value |
---|---|
Position Security Profile |
Create New |
Name |
ABC Industrial Positions - Top Position Vice President of Sales |
Secure by position hierarchy |
Yes |
Field |
Value |
---|---|
Person Security Profile |
Create New |
Name |
ABC Industrial Sales Department - All Workers and Worker Contacts |
Include related contacts |
Yes |
Secure by person type |
Yes |
Secure by department |
Yes |
Field |
Value |
---|---|
Tree Structure |
Generic organization hierarchy |
Organization Tree |
ABC Industrial Organization Tree |
Top Organization Selection |
Use the assignment department |
Include top organization |
Yes |
Field |
Value |
---|---|
Position Tree |
ABC Industrial Positions |
Top Position Selection |
Specify top position |
Position |
Vice President of Sales |
Include top position |
Yes |
Type |
System Person Type |
Access |
---|---|---|
System |
Employee |
Restricted |
System |
Contingent worker |
Restricted |
System |
Nonworker |
Restricted |
System |
Pending worker |
Restricted |
Abstract roles define a worker's role in the enterprise independently of the job that the worker is hired to do.
These abstract roles are predefined in Oracle Fusion Human Capital Management:
Line manager
Employee
Contingent worker
Typically, you create role mappings during implementation to provision abstract roles automatically to eligible workers. Although users with these roles may be able to sign in to Oracle Fusion Applications and navigate to tasks of interest, they have no automatic access to data. For example, employees can navigate to the Person Gallery but cannot view portraits or see lists of person names in product interfaces, and line managers can navigate to the Manager Resources Dashboard but can see no data for their organizations. To enable users with abstract roles to access relevant HCM data, you must assign security profiles to those abstract roles.
To enable users with abstract roles to access relevant data, you assign the following predefined security profiles directly to the employee, contingent worker, and line manager abstract roles.
Security Profile Type |
Employee |
Contingent Worker |
Line Manager |
---|---|---|---|
Person |
View Own Record |
View Own Record |
View Manager Hierarchy |
Public person |
View All Workers |
View All Workers |
View All Workers |
Organization |
View All Organizations |
View All Organizations |
View All Organizations |
Position |
View All Positions |
View All Positions |
View All Positions |
Legislative data group |
View All Legislative Data Groups |
View All Legislative Data Groups |
View All Legislative Data Groups |
Country |
View All Countries |
View All Countries |
View All Countries |
Document type |
View All Document Types |
View All Document Types |
View All Document Types |
Payroll Flow |
Not applicable |
Not applicable |
View All Flows |
Workforce Business Process |
Not applicable |
Not applicable |
View All Workforce Business Processes |
After implementation, you may want to change aspects of this data access. For example, you may want to create your own security profiles and assign those directly to abstract roles; however, you must remember that such changes apply to all users who have the abstract role.
Users who have abstract roles are likely to gain additional data access by means of HCM data roles that you define for their job roles. For example, you may create an HCM data role for human resource specialists to enable them to access the person records of all workers in a legal employer. Such data access is in addition to any data access provided by abstract roles.
This example shows how to assign predefined security profiles to the employee, contingent worker, and line manager abstract roles.
Field |
Value |
---|---|
Organization Security Profile |
View All Organizations |
Position Security Profile |
View All Positions |
Country Security Profile |
View All Countries |
LDG Security Profile |
View All Legislative Data Groups |
Person Security Profile (Person section) |
View Own Record |
Person Security Profile (Public Person section) |
View All Workers |
Document Type Security Profile |
View All Document Types |
Repeat the steps in Searching for the Employee Abstract Role and Assigning Security Profiles to the Employee Abstract Role for the predefined Contingent Worker role.
Field |
Value |
---|---|
Organization Security Profile |
View All Organizations |
Position Security Profile |
View All Positions |
LDG Security Profile |
View All Legislative Data Groups |
Person Security Profile (Person section) |
View Manager Hierarchy |
Person Security Profile (Public Person section) |
View All Workers |
Document Type Security Profile |
View All Document Types |
Payroll Flow |
View All Flows |
Workforce Business Process |
View All Workforce Business Processes |
The HCM Data Roles Configuration diagnostic test verifies that the Manage HCM Data Roles task flow is configured successfully for a specified user.
You run the HCM Data Roles Configuration diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.
Diagnostic Test Parameters
User Name
The test is performed for the specified user. The user does not need to be signed-in while the test is running; however, the user must have signed in at least once, because the test uses details from the user's current or latest session.
The HCM Security Profile Configuration diagnostic test verifies that the Manage Security Profiles task flows are configured successfully for a specified user.
You run the HCM Security Profile Configuration diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.
Diagnostic Test Parameters
User Name
The test is performed for the specified user. The user does not need to be signed-in while the test is running; however, the user must have signed in at least once, because the test uses details from the user's current or latest session.
The HCM Securing Objects Metadata diagnostic test validates securing-object metadata for the HCM securing objects.
You run the HCM Securing Objects Metadata diagnostic test from the Help - Troubleshooting - Run Diagnostic Tests menu.
Diagnostic Test Parameters
Securing Object
Enter the name of an HCM securing object from the following table.
Securing Object Name |
Description |
---|---|
PERSON |
Person |
LDG |
Legislative data group |
POSITION |
Position |
ORGANIZATION |
Organization |
PAYROLL |
Payroll |
FLOWPATTERN |
Payroll flow |
DOR |
Document type |
COUNTRY |
Country |
If you do not enter the name of a securing object, the test is performed for all securing objects.
Having access to a person's record does not automatically provide access to the records of that person's emergency contacts, dependents, or beneficiaries. However, you can include the person records of a person's contacts in the person security profile's data instance set by selecting the Include related contacts option.
Note
If a person's contact is also a worker, the contact's person record is excluded from the person security profile's data instance set, even when Include related contacts is selected, unless the contact's person record satisfies all other criteria in the security profile.
A user who has access to a person record also has access to all of the person's assignments; only one of the assignments has to satisfy any assignment-related criteria in the person security profile. For example, if a user can access the records of contingent workers in a particular legal employer and department, then the user can access all assignments belonging to those contingent workers, even if some are employee or nonworker assignments with different legal employers.
Some person records, such as those of emergency contacts, have no assignments. The person records of people who have no assignments do not need to satisfy any assignment-related criteria, such as department and position, in the person security profile. Person records without assignments belong to the person security profile data instance set, provided that they satisfy any person-related criteria (person type, global name range, or custom criteria) in the person security profile. Such records are an exception to the general rule that all of the criteria in a security profile must be satisfied.
A generic organization hierarchy is a single hierarchy that includes organizations of all classifications, such as division, legal entity, department, and tax reporting unit.
A department hierarchy includes only those organizations that are classified as departments.
If you secure by department, for example, only those organizations in the generic organization hierarchy that are classified as departments have an effect in the security profile. Other types of organizations in the generic organization hierarchy, such as business units and legal employers, are disregarded.
If you secure by more than one workforce structure, you can select the same organization security profile for each type of work structure. In each case, only organizations of the relevant organization classification have an effect.
The access that each user has to the organization or position hierarchy depends on the user's assignments. Consequently, the data instance set from a single security profile can be different for each user.
If the user has multiple assignments in the selected organization or position hierarchy, then multiple top organizations or positions may exist. In this case, all organizations or positions from the relevant subhierarchies belong to the security profile's data instance set.
Country security profiles identify one or more countries to appear in lists of countries. For example, a user who is creating a legislative data group must associate it with a country; the list of countries that the user sees is determined by the country security profile included in the user's HCM data role. The predefined country security profile View All Countries meets most needs and can be included in any HCM data role. However, you can limit the country list available to a particular HCM data role by creating a country security profile for that data role. The countries that you can include in the country security profile are those defined in the table FND_TERRITORIES.
You need a legislative data group (LDG) security profile to identify one or more LDGs to which you want to secure access. If the responsibility for managing all LDGs in your enterprise belongs to a particular HCM data role, include the predefined LDG security profile View All Legislative Data Groups in the data role. If responsibility for particular LDGs belongs to various HCM data roles, you can create an appropriate LDG security profile for each data role. For example, if European and American LDGs are the responsibility of different HCM data roles, you need one LDG security profile for European LDGs and one for American LDGs.
You can use an LDG security profile to secure access to person records. In this case, if the LDG is associated with the payroll statutory unit of a person's legal employer, then that person's record belongs to the person security profile data instance set.
Workforce business process security profiles identify the workforce business processes that a user can start from the Start Process menu in the Workforce Processes work area. The predefined security profile View All Workforce Business Processes includes all registered workforce business processes. To enable users to start all workforce business processes, you include the predefined security profile in relevant HCM data roles; you do not need to create a workforce business process security profile to provide this access.
To enable users to start some but not all workforce business processes, you must:
Create a workforce business process security profile that identifies the workforce business processes that the user can start.
Include the new workforce business process security profile in relevant HCM data roles.
If the security profile is included in an HCM data role, then the data instance set for the security profile is updated automatically when you save your changes. For example, if you remove a position from a position security profile, the position is removed from the data instance set of the relevant position security profile. At the next attempt to access the data identified in the security profile, the user finds the updated data instance set.
When the security profile is included in an HCM data role, users continue to access the tasks associated with their job roles or abstract roles because security profiles have no effect on function security privileges. However, no data is returned from the disabled security profile. For example, an administrator authorized to update organization definitions would continue to access organization-related tasks, but would not be able to access the organizations identified in a disabled organization security profile.
You cannot disable a security profile that is included in another security profile.
You can map any role, including HCM data roles, to one or more assignment attributes. For example, you can map a role to a particular legal employer, department, and job. This mapping indicates that the role is relevant to users whose assignment attributes match those specified.
If the role mapping for a role has the Autoprovision option selected, then the role is provisioned automatically to any user with at least one assignment that matches all specified attributes.
If the role mapping for a role has the Requestable option selected, then any human resource specialist or line manager with at least one assignment that matches all specified attributes can provision the role manually to other users.
If the role mapping for a role has the Self-requestable option selected, then any user with at least one assignment that matches all specified attributes can request the role.
You can edit or replace the existing security profiles in an HCM data role. When you save your changes, the relevant data instance sets are updated. Users with this HCM data role find the revised data instance sets when they next sign in.
You cannot change the HCM data role name nor select a different job role. If you need to make such changes, you must create a new HCM data role and disable this HCM data role, if appropriate.
After creating HCM data roles and security profiles, you can run diagnostic tests from the Help - Troubleshooting - Run Diagnostic Tests menu to diagnose any issues.
The following diagnostic tests are available:
Diagnostic Test Name |
Description |
---|---|
HCM Data Roles Configuration |
Verifies that the Manage HCM Data Roles task flow is configured successfully for a specified user. |
HCM Data Role Detailed Information |
Identifies any potential issues with a specified HCM data role. |
HCM Security Profile Configuration |
Verifies that the Manage Security Profiles task flows are configured successfully for a specified user. |
HCM Security Profiles Detailed Information |
Identifies any potential issues with one or all security profiles of a specified type. |
HCM Securing Objects Metadata |
Validates securing-object metadata for the HCM securing objects. |