Oracle® Fusion Applications Compensation Management Implementation Guide 11g Release 1 (11.1.3) Part Number E20376-03

Contents

Previous

Next

9 Common Applications Configuration: Define Security for Human Capital Management

This chapter contains the following:

Role Provisioning and Deprovisioning: Explained

Role Mappings: Explained

Role Mappings: Examples

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

Role Provisioning and Deprovisioning: Explained

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.

Role Provisioning Methods

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.

Role Types

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.

Automatic Role Provisioning

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.

Role Deprovisioning

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.

Changes to Assignment Managers

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.

Roles at Termination

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.

Date-Effective Changes to Assignments

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.

Role Mappings: Explained

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

Automatic Provisioning of Roles to Users

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.

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.

Manual Provisioning of Roles to Users

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.

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.

Role Requests from Users

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.

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.

Immediate Provisioning of Roles

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.

Role-Mapping Names

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:

Role Mappings: Examples

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.

Creating a Role Mapping for Employees

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.

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.

Creating a Role Mapping for Line Managers

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.

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.

Creating a Role Mapping for Retirees

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.

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.

Creating a Role Mapping for Sales Managers

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.

In the role mapping, you include the:

• Sales Manager role, and select the Autoprovision option

• Sales Associate role, and select the Requestable option

Synchronization of User and Role Information with Oracle Identity Management: How It Is Processed

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.

Settings That Affect Synchronization of User and Role Information

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 you specify a batch size of 25, 16 batches of requests will be created and processed in parallel if there are 400 requests to be processed.

How Synchronization of User and Role Information Is Managed

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.

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.

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

• Latest start date of the current period of service

• The GUIDs of all of the person's managers

• Work e-mail address, if Oracle Fusion HCM owns the work e-mail address

• Work mobile phone number

• Work phone number

• Work FAX number

• Both the display name and the following name components in all languages in which they have been created in the person record:

  • 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

No personally identifiable information (PII) is sent from Oracle Fusion HCM to OIM.

Defining Security After Enterprise Setup: Points to Consider

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.

Before Importing 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.

If role provisioning rules have been defined, the Import Person and Organization task automatically provisions role requests as the users are created.

Import Users

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.

Manage Job Roles

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.

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.

Manage Duties

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.

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.

Manage Application Access Controls

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) .

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.

Defining Data Security After Enterprise Setup: Points to Consider

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).

Manage Data Access Sets

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.

Manage Segment Security

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.

Manage Role Templates

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.

Manage Data Security Policies

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.

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.

Manage Encryption Keys

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.

Securing Identities and Users: Points To Consider

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.

Stores

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.

Importing Users

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.

Provisioning Events

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.

Notifications and Audits

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.

Delegated Administration

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.

Credentials

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.

Define Data Security for Human Capital Management

HCM Data Roles: Explained

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.

How HCM Data Roles Differ from Other Data Roles

HCM data roles differ from other data roles in the following ways:

• You create and maintain HCM data roles outside 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.

Selecting the Job Role

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.

Creating or Selecting the Security Profiles

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.

Users with Multiple HCM Data Roles

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.

Components of the HCM Data Role

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.

HCM Securing and Secured Objects: Explained

Human capital management (HCM) objects to which access is secured by HCM data roles are identified as either securing objects or secured objects.

HCM Securing 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.

HCM Secured Objects

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.

HCM Security Profiles: Explained

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.

HCM Object Types

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.

Security Criteria in HCM Security Profiles

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.

Predefined HCM Security Profiles

The following HCM security profiles are predefined:

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.

Creating Security Profiles

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.

Reusability and Inheritance of Security Profiles

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.

Creating HCM Data Roles and Security Profiles: Points to Consider

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.

Identifying Standard Requirements

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.

Naming HCM Data Roles and Security Profiles

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.

Planning Data Access for Each HCM Data Role

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.

Providing Access to All Instances of an Object

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.

Creating Organization Security Profiles: Examples

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.

HR IT Administrator Who Maintains Organizations

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.

Human Resource Specialist Who Manages Person and Assignment Records in a Legal Employer

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.

Creating Person Security Profiles: Examples

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 Specialists for a Legal Employer

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.

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.

Enterprise Line Managers

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 select the assignment-level option.

• Set the maximum levels in the hierarchy to 3, to ensure that the data instance set for any line manager comprises no more than 3 levels of the manager hierarchy.

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 for a Subset of Employees

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.

Creating Position Security Profiles: Examples

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.

Human Resource Specialist Managing Position Definitions

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 Manager Hiring Workers

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.

Securing Person Records by Position

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.

Creating Document Type Security Profiles: Examples

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.

These scenarios show typical uses of document type security profiles.

Workers Managing Their Own Documents

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 Managing Document Types

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.

Securing Organizations: Points to Consider

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 With Multiple Classifications

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.

Selecting the Top Organization in an Organization Hierarchy

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.

Users With Multiple Assignments

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.

Securing Person Records Using Custom Criteria: Examples

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.

Identifying Persons Born Before a Specified Date

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'))

Securing Person Records by Manager Hierarchy: Points to Consider

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.

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.

Person-Level Manager Hierarchy

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).

Assignment-Level Manager Hierarchy

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.

Securing Person Records by Workforce Structures: Points to Consider

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.

Identifying the Work Structures

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.

Using Assignment-Level Attributes

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.

Securing Person Records by LDG

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.

Securing Person Records by Payroll

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.

Securing Person Records by Legal Employer

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.

Creating an HCM Data Role: Worked Example

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.

Summary of the Tasks

Create the HCM data role by:

1. Naming the HCM data role and selecting the associated job role

2. Specifying the security criteria for each HCM object type

3. Creating new security profiles

4. Reviewing and submitting the new HCM data role

Naming the HCM Data Role and Selecting the Job Role

1. In the Search Results region of the Manage HCM Data Roles page, click Create.
2. On the Create Data Role: Select Role page, complete the fields as shown in this table.

   Field	Value
   Data Role	HR Specialist ABC Industrial - Sales Department
   Job Role	Human Resource Specialist

   
   
3. Click Next.

Specifying Security Criteria for Each HCM Object Type

1. In the Organization region of the Create Data Role: Security Criteria page, complete the fields as shown in the table.

   Field	Value
   Organization Security Profile	Create New
   Name	ABC Industrial - All Organizations
   Secure by organization hierarchy	Yes

   
   
2. In the Position region, complete the fields as shown in the table

   Field	Value
   Position Security Profile	Create New
   Name	ABC Industrial Positions - Top Position Vice President of Sales
   Secure by position hierarchy	Yes

   
   
3. In the Countries region, select the predefined country security profile View All Countries.
4. In the Legislative Data Group region, select the existing LDG security profile ABC Industrial LDGs.
5. In the Person region, complete the fields as shown in the table.

   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

   
   
6. In the Public Person region, select the predefined person security profile View All People.
7. In the Document Type region, select the predefined document type security profile View All Document Types.
8. In the Payroll region, select the existing payroll security profile ABC Industrial Payrolls.
9. In the Payroll Flow region, select the existing payroll flow security profile ABC Industrial Payroll Flows.
10. Click Next.

Creating the Organization Security Profile

1. In the Organization Hierarchy region of the Assign Security Profiles to Role: Organization Security Profile page, ensure that the Secure by organization hierarchy option is selected.
2. Complete the fields in the Organization Hierarchy region as shown in the table.

   Field	Value
   Tree Structure	Generic organization hierarchy
   Organization Tree	ABC Industrial Organization Tree
   Top Organization Selection	Use the assignment department
   Include top organization	Yes

   
   
3. Click Next.

Creating the Position Security Profile

1. In the Position Hierarchy region of the Assign Security Profiles to Role: Position Security Profile page, ensure that the Secure by position hierarchy option is selected.
2. Complete the fields in the Position Hierarchy region as shown in the table.

   Field	Value
   Position Tree	ABC Industrial Positions
   Top Position Selection	Specify top position
   Position	Vice President of Sales
   Include top position	Yes

   
   
3. Navigate to the Assign Security Profile to Role: Person Security Profile page.

Creating the Person Security Profile

1. In the Basic Details region of the Assign Security Profiles to Role: Person Security Profile page, ensure that the option Include related contacts is selected.
2. In the Person Types region, ensure that the Secure by person type option is selected, and complete the fields as shown in the table.

   Type	System Person Type	Access
   System	Employee	Restricted
   System	Contingent worker	Restricted
   System	Nonworker	Restricted
   System	Pending worker	Restricted

   
   
3. In the Workforce Structures region, ensure that the option Secure by department is selected, and select the existing organization security profile ABC Industrial - Sales Department.
4. Click Review.

Review and Submit the HCM Data Role

1. On the Create Data Role: Review page, review the new HCM data role.
2. Click Submit.
3. On the Manage HCM Data Roles page, search for the new HCM data role. In the search results, confirm that the role status is Requested. Once the role status is Request Complete, the role can be provisioned to users.

Setting Up Data Security for Employees: Worked Example

Oracle Fusion Applications users may need to access Oracle Fusion Human Capital Management (HCM) person data, such as lists of person names, in their product interfaces. To provide this access, you assign predefined HCM security profiles to relevant abstract roles, such as Employee. This example shows how to assign security profiles to the Employee abstract role.

Searching for the Abstract Role

1. In the Functional Setup Manager (FSM), click Go to Task for the Manage Data Role and Security Profiles task.
2. On the Manage HCM Data Roles page, enter the abstract role name Employee in the Role field.
3. Click Search.
4. In the search results, highlight the entry for the Employee role.
5. Click Assign.

Assigning Security Profiles to the Abstract Role

1. On the Assign Data Role: Security Criteria page use the default values, as shown in this table.

   Field	Value
   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

   
   

   These are the security profiles that are typically assigned to the Employee abstract role. You may see a subset of these security profiles, depending on the combination of product offerings that you are implementing.

2. Click Review.
3. On the Assign Data Role: Review page, click Submit.

FAQs for Define Data Security for Human Capital Management

Can users access the contact records of the people they can access?

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.

What happens if a person has multiple assignments or person types?

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.

What happens if a person has no assignments?

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.

What's the difference between a generic organization hierarchy and a department hierarchy?

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.

What happens if I select an organization security profile for a generic organization hierarchy?

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.

What happens if I use the department or position from the user's assignment as the top department or position?

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.

When do I need a country security profile?

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.

When do I need a legislative data group security profile?

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.

When do I need a workforce business process security profile?

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.

What happens if I edit a security profile that's enabled?

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.

What happens if I disable a security profile?

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.

How do I provision HCM data roles to users?

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.

What happens if I edit an HCM data 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.

Previous Next

Copyright ©  2011, Oracle and/or its affiliates. All rights reserved. Legal Notices

Contents Contact Us