Oracle® Fusion
Applications Sales Implementation Guide 11g Release 1 (11.1.2) Part Number E20373-02 |
![]() Contents |
![]() Previous |
![]() Next |
This chapter contains the following:
Defining Security After Enterprise Setup: Points to Consider
Security Tasks and Oracle Fusion Applications: How They Fit Together
Security tasks include the following.
Security setup
Security implementation and administration
Note
Perform security tasks in the integrated Oracle Fusion Applications user interfaces that are provided by the following products.
Oracle Identity Manager (OIM)
Oracle Authorization Policy Manager (APM)
Oracle Fusion Human Capital Management (HCM) products
Oracle Application Access Control Governor (AACG) in Governance, Risk, and Compliance Controls (GRCC)
Security administrative tasks performed by product administrators and implementation consultants, such as managing HCM security profiles, are presented in the documentation for those products.
Sign into Oracle Fusion Applications for the first time with the super user account to create an IT security manager user account and provision it with the IT Security Manager role. With that account, perform the required security administration tasks.
Establish at least one implementation user and provision that user with sufficient access to set up the enterprise for all integrated Oracle Fusion Middleware and all application pillars or partitions. Initial security administration includes creating an implementation user, creating a data role for setting up HCM, and provisioning the implementation user with that data role so that the enterprise can be set up with Human Resources (HR) structures. Setup of business units, accounting structures, reference data sets, and so on does not require creation of an HCM administrator data role.
Once initial security administration is complete and your enterprise is set up with structures such as business units, additional security administration tasks are optional and based on modifying and expanding the predefined security reference implementation to fit your enterprise. See points to consider for defining security, data security and trading partner security after enterprise setup.
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.
The major security tasks and their order within the context of an overall Oracle Fusion Applications implementation extend from security setup through production deployment audits.
The Oracle Fusion business process model (BPM) provides a sequence of security implementation tasks that includes the following.
Security setup (Define Common Applications Configuration activity)
Define Implementation Users task group (optional)
Create Implementation Users task
Create Data Role for Implementation Users task
Assign Roles to Implementation Users task
Define security - tasks vary depending on deployed Oracle Fusion product family
Revoke Data Role from Implementation Users task
Import Worker Users task
Import Partner Users task
Manage Duties task
Manage Job Roles task
Manage Application Access Controls task
Define Automated Governance, Risk, and Performance Controls activity
Manage Application Access Controls task (AACG settings)
Manage Application Preventive Controls task
Manage Application Transaction Controls task
Manage Application Configuration Controls task
User and role provisioning tasks
Implement Role Request and Provisioning Controls activity
Import Worker Users task
Import Partner Users task
Self Request User Roles task
Approve User and Role Provisioning Requests task
Assign User Roles task
Manage Supplier User Roles and User Role Usages task
Map and Synchronize User Account Details task
Tasks for viewing account details for self or others
Tasks for applying and managing various role provisioning rules
Tasks for running synchronization processes
Security implementation and ongoing maintenance after setup (Manage IT Security activity)
Implement Function Security Controls
Create Job Role task
Import Worker Users task
Import Partner Users task
Manage Duties task
Manage Job Roles task
Manage Users task
Implement Data Security Controls
Manage Data Security Policies task
Manage Role Templates task
Manage Encryption Keys task
Manage Segment Security task
Manage Data Access Sets task
Define Security Profiles task group
Auditing tasks
Manage Security Audit, Compliance and Reporting activity
Manage Application Access Controls task
Note
Go live deployment does not require lockdown or specific security tasks because security is enforced across the test to production information life cycle.
The Oracle Fusion Applications installation process sets up a single, super user provisioned with the following enterprise roles.
Application Implementation Consultant
IT Security Manager
Application Administrators for the provisioned products
Additionally, provision the super user with the following roles to enable user and role administration in Oracle Identity Management (OIM) and the Authorization Policy Manager (APM).
Identity User Administrator
Role Administrator
APM Administration Application
Important
As a security guideline, provision a dedicated security professional with the IT Security Manager role as soon as possible after initial security setup and revoke that role from users provisioned with the Application Implementation Consultant role.
The user provisioned with the IT Security Manager role should additionally be provisioned with the following roles.
Identity User Administrator for access to user administration in OIM
Role Administrator for access to role administration in OIM
APM Administration Application role for access to administration in the Authorization Policy Manager
Provision these roles to the IT security manager using the XELSYSADM user in OIM.
Security tasks are supported by tools within both Oracle Fusion Applications and Oracle Fusion Middleware.
The figure lists the tasks associated with each of the integrated products and pillars of an Oracle Fusion Applications deployment.
Security tasks span multiple business processes and are performed by various roles using numerous integrated tools.
The following table shows the business process model (BPM) tasks and tools used to support securing Oracle Fusion Applications.
Example Task |
Oracle BPM Task |
Supporting Tools |
Details |
---|---|---|---|
View duty roles inherited by a job role |
Manage Duties |
|
Each logical partition or pillar contains a collection of application roles, and function and data security policies. |
View entitlement or policies carried by a job role |
Manage Duties |
|
In LDAP, the policy store stores application roles and the identity store stores enterprise roles. |
Add a job role to a role hierarchy |
Manage Job Roles |
|
The identity store in LDAP stores enterprise roles. |
Add a duty role to a role hierarchy |
Manage Duties |
|
LDAP stores the role hierarchy and the spanning of roles across multiple pillars or logical partitions. |
Create a hierarchy of enterprise (abstract, job, data) roles |
Manage Job Roles |
|
|
Create a hierarchy of (application) duty roles |
Manage Duties |
|
|
Create a new job role |
|
|
The identity store in LDAP stores enterprise roles. |
Change duty roles inherited by a job or abstract role |
Manage Duties |
|
The policy store stores duty roles. The identity store stores enterprise roles. Some duty roles may enable actions and their associated users interface features that your enterprise does not want users to perform in Oracle Fusion applications. |
Create a new duty role |
Manage Duties |
|
All functions and actions in Oracle Fusion Applications that need to be secured are covered by the reference implementation. In some cases, especially with function customizations, a new duty role may be needed. |
View Segregation of Duties (SOD) policies respected by a duty role |
Manage Application Access Controls |
|
The Security Reference Manuals (SRM) document the segregation of duties (SOD) policies respected within each job role |
View SOD policy violations carried by the duty roles inherited by a job role |
Manage Application Access Controls |
|
The Security Reference Manuals (SRM) document the SOD policies respected within each job role |
View SOD policy violations |
Manage Segregation of Duties Policies |
|
The SRM documents the SOD conflicts for each job role |
View the data security policies carried by a job, abstract, and data roles |
Manage Data Security Policies |
|
Oracle Fusion Data Security stores data security policies in the policy store. Data security can also be defined in application pages provided by Oracle Middleware Extensions for Applications (FND) |
Create and update HCM security profiles |
Manage Data Role and Security Profiles |
|
This task does not include assigning data roles to the users, which is supported by user provisioning tasks. |
Create (generate) a data role |
|
|
Data roles are generated automatically based on data role templates and enterprise setup. Changes to data role templates generate new or changed data roles. Create data roles in HCM using the Manage Data Roles and Security Profiles task. |
Create a new data security policy (not through generated data roles based on data role templates or HCM security profiles) |
Manage Data Security Policies |
|
Data security can also be defined in application pages provided by Oracle Middleware Extensions for Applications (FND) |
View data role templates defined by a product |
Manage Role Templates |
|
|
Create or edit an existing data role template |
Manage Role Templates |
|
|
Secure common objects such as attachment categories or profile options |
Manage Data Security Policies |
|
Data security can also be defined in application pages provided by Oracle Middleware Extensions for Applications (FND) |
View, create, update encryption keys used to secure attributes of personally identifiable information |
Manage Encryption Keys |
|
|
View, create, update Data Access Sets used to secure Ledgers and Ledger Sets |
Manage Data Access Sets |
|
|
View, create, update accounting flexfield segment security rules |
Manage Security Segments |
|
|
View or update the set of job roles that can be provisioned to supplier users |
Manage Supplier User Role |
|
These tools are in the Oracle Fusion Procurement product family |
Determine the supplier job roles that the supplier self service administrator can provision to supplier users |
Manage Supplier User Role Usages |
|
These tools are in the Oracle Fusion Procurement product family |
Set default supplier job roles based on the set of supplier roles that are defined by performing the Manage Supplier User Roles task |
Manage Supplier User Role Usages |
|
These tools are in the Oracle Fusion Procurement product family |
Create a new implementation user |
Create Implementation Users |
|
|
Import legacy users |
|
|
|
Create a new user |
Manage Users |
|
HCM creates a new user and identity when a new worker is created. The Hire Employee and Add Contingent Worker tasks also result in new user creation requests. Creating a new user automatically triggers role provisioning requests based on role provisioning rules. |
Provision roles to a user |
|
|
Implementation users are provisioned through OIM since HCM is not setup at the start of the implementation. The Provision Roles to Implementation Users is not needed once implementation is complete. Once HCM is setup, HCM is used to provision roles to non-implementation users by performing the Manage Users task. Human Resources (HR) transaction flows such as Hire and Promote also provision roles. Once supplier users are setup, Supplier Model can be used by internal users to maintain supplier user accounts or supplier users can maintain their accounts in Supplier Portal. |
View the job, abstract, and data roles provisioned to a user |
|
|
LDAP stores users, roles and provisioning information. The Manage User Principal and Provision Roles to Implementation Users tasks are not needed once implementation is complete. |
Revoke role from user. |
Manage Users |
|
You can revoke roles from various Human Resources task flows, the HCM Manage Users task and OIM. User termination includes role revocation. |
Approve role provisioning or user account request. |
Approve User and Role Provisioning Requests |
|
|
View audit logs |
Not applicable |
|
Viewing audit logs is a Oracle Fusion Middleware function and not represented by an Oracle Fusion Applications BPM task. |
For more information about provisioning identities and configuring audit policies, see the Oracle Fusion Applications Administrator's Guide.
There may be more than one navigation path to the graphical user interface in which the task is performed. You can access most security tasks by starting in the Setup and Maintenance Overview page and searching for security tasks and task lists.
By default, users are denied access to all data.
Data security makes data available to users by the following means.
Policies that define grants available through provisioned roles
Policies defined in application code
You secure data by provisioning roles that provide the necessary access. Enterprise roles provide access to data through data security policies defined for the inherited application roles.
When setting up the enterprise with structures such as business units, data roles are automatically generated that inherit job roles based on data role templates. Data roles also can be generated based on HCM security profiles. Data role templates and HCM security profiles enable defining the instance sets specified in data security policies.
When you provision a job role to a user, the job role implicitly limits data access based on the data security policies of the inherited duty roles. When you provision a data role to a user, the data role explicitly limits the data access of the inherited job role to a dimension of data.
Data security consists of privileges conditionally granted to a role and used to control access to the data. A privilege is a single, real world action on a single business object. A data security policy is a grant of a set of privileges to a principal on an object or attribute group for a given condition. A grant authorizes a role, the grantee, to actions on a set of database resources. A database resource is an object, object instance, or object instance set. An entitlement is one or more allowable actions applied to a set of database resources.
Data is secured by the following means.
Data security feature |
Does what? |
---|---|
Data security policy |
Grants access to roles by means of entitlement |
Role |
Applies data security policies with conditions to users through role provisioning. |
Data role template |
Defines the data roles generated based on enterprise setup of data dimensions such as business unit. |
HCM security profile |
Defines data security conditions on instances of object types such as person records, positions, and document types without requiring users to enter SQL code |
Masking |
Hides private data on non-production database instances |
Encryption |
Scrambles data to prevent users without decryption authorization from reading secured data |
The sets of data that a user can access via roles are defined in Oracle Fusion Data Security. Oracle Fusion Data Security integrates with Oracle Platform Security Services (OPSS) to entitle users or roles (which are stored externally) with access to data. Users are granted access through the entitlement assigned to the roles or role hierarchy with which the user is provisioned. Conditions are WHERE clauses that specify access within a particular dimension, such as by business unit to which the user is authorized.
Data security policies articulate the security requirement "Who can do What on Which set of data," where 'Which set of data' is an entire object or an object instance or object instance set and 'What' is the object entitlement.
For example, accounts payable managers can view AP disbursements for their business unit.
Who |
can do |
what |
on which set of data |
---|---|---|---|
Accounts payable managers |
view |
AP disbursements |
for their business unit |
A data security policy is a statement in a natural language, such as English, that typically defines the grant by which a role secures business objects. The grant records the following.
Table or view
Entitlement (actions expressed by privileges)
Instance set (data identified by the condition)
For example, disbursement is a business object that an accounts payable manager can manage by payment function for any employee expenses in the payment process.
Note
Some data security policies are not defined as grants but directly in applications code. The security reference manuals for Oracle Fusion Applications offerings differentiate between data security policies that define a grant and data security policies defined in Oracle Fusion applications code.
A business object participating in a data security policy is the database resource of the policy.
Data security policies that use job or duty roles refer to data security entitlement.
For example, the data security policy for the Accounts Payable Manager job role refers to the view action on AP disbursements as the data security entitlement.
Important
The duty roles inherited by the job role can be moved and job roles reassembled without having to modify the data security.
As a security guideline, data security policies based on user session context should entitle a duty role. This keeps both function and data security policies at the duty role level, thus reducing errors.
For example, a Sales Party Management Duty can update Sales Party where the provisioned user is a member of the territory associated with the sales account. Or the Sales Party Management Duty can update Sales Party where the provisioned user is in the management chain of a resource who is on the sales account team with edit access. Or the Participant Interaction Management Duty can view an Interaction where the provisioned user is a participant of the Interaction.
For example, the Disbursement Process Management Duty role includes entitlement to build documents payable into payments. The Accounts Payable Manager job role inherits the Disbursement Process Management Duty role. Data security policies for the Disbursement Process Management Duty role authorize access to data associated with business objects such as AP disbursements within a business unit. As a result, the user provisioned with the Accounts Payable Manager job role is authorized to view AP disbursements within their business unit.
A data security policy identifies the entitlement (the actions that can be made on logical business objects or dashboards), the roles that can perform those actions, and the conditions that limit access. Conditions are readable WHERE clauses. The WHERE clause is defined in the data as an instance set and this is then referenced on a grant that also records the table name and required entitlement.
Data roles are implemented as job roles for a defined set of data.
A data role defines a dimension of data within which a job is performed. The data role inherits the job role that describes the job. For example, a data role entitles a user to perform a job in a business unit.
The data role inherits abstract or job roles and is granted data security privileges. Data roles carry the function security privileges inherited from job roles and also the data security privilege granted on database objects and table rows.
For example, an accounts payables specialist in the US Business Unit may be assigned the data role Accounts Payables Specialist - US Business Unit. This data role inherits the job role Accounts Payables Specialist and grants access to transactions in the US Business Unit.
A data role may be granted entitlement over a set people.
For example, a Benefits Administrator A-E is allowed to administer benefits for all people that have a surname that begins with A-E.
Data roles are created using data role templates. You create and maintain data roles in the Authorization Policy Manager (APM). Use the Manage Data Roles and Security Profiles task to create and maintain HCM data roles in Oracle Fusion HCM.
HCM security profiles are used to secure HCM data, such as people and departments. You use HCM security profiles to generate grants for an enterprise role. The resulting data role with its role hierarchy and grants operates in the same way as any other data role.
For example, an HCM security profile identifies all employees in the Finance division.
Oracle Fusion Payroll uses HCM security profiles to secure project organizations. Applications outside of HCM can use the HCM Data Roles UI pages to give their roles access to HR people.
Oracle Fusion Applications uses masking to protect sensitive data from view by unauthorized users. Encryption APIs mask sensitive fields in applications user interfaces. Additionally, Oracle Data Masking is available for masking data in non-production instances and Oracle Transparent Data Encryption is available for protecting data in transit or in backups independent of managing encryption keys.
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.
The reference implementation contains a set of data security policies that can be inspected and confirmed to be suitable or a basis for further implementation using the Authorization Policy Manager (APM).
The security implementation of an enterprise is likely a subset of the reference implementation, with the enterprise specifics of duty roles, data security policies, and HCM security profiles provided by the enterprise.
The business objects registered as secure in the reference implementation are database tables and views.
Granting or revoking object entitlement to a particular user or group of users on an object instance or set of instances extends the base Oracle Fusion Applications security reference implementation without requiring customization of the applications that access the data.
The data security policies in the reference implementation entitle the grantee (a role) to access instance sets of data based on SQL predicates in a WHERE clause.
Tip
When extending the reference implementation with additional data security policies, identify instance sets of data representing the business objects that need to be secured, rather than specific instances or all instances of the business objects.
Predefined data security policies are stored in the data security policy store, managed in the Authorization Policy Manager (APM), and described in the Oracle Fusion Applications Security Reference Manual for each offering. A data security policy for a duty role describes an entitlement granted to any job role that includes that duty role.
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.
The reference implementation only enforces a portion of the data security policies in business intelligence that is considered most critical to risk management without negatively affecting performance. For performance reasons it is not practical to secure every level in every dimension. Your enterprise may have a different risk tolerance than assumed by the security reference implementation.
The security reference implementation includes some predefined HCM security profiles for initial usability. For example, a predefined HCM security profile allows line managers to see the people that report to them.
The IT security manager uses HCM security profiles to define the sets of HCM data that can be accessed by the roles that are provisioned to users
The security reference implementation includes no predefined data roles to ensure a fully secured initial Oracle Fusion Applications environment.
The security reference implementation includes data role templates that you can use to generate a set of data roles with entitlement to perform predefined business functions within data dimensions such as business unit. Oracle Fusion Payables invoicing and expense management are examples of predefined business functions. Accounts Payable Manager - US is a data role you might generate from a predefined data role template for payables invoicing if you set up a business unit called US.
HCM provides a mechanism for generating HCM related data roles.
Oracle Fusion Applications supports securing data through role-based access control (RBAC) by the following methods.
Method of securing data |
Reason |
Example |
---|---|---|
Data roles apply explicit data security policies on job and abstract roles |
Appropriate for job and abstract roles that should only access a subset of data, as defined by the data role template that generates the data role or by HCM security profiles. |
Accounts Payable Manager - US data role to provide an accounts payable manager in the US business unit with access to invoices in the US business unit. |
Data security policies |
Define data access for application roles and provide inheriting job and abstract roles with implicit data security |
Projects |
If a user has access to the same function through different roles that access different data sets, then the user has access to a union of those data sets.
When a runtime session is created, Oracle Platform Security Services (OPSS) propagates only the necessary user to role mapping based on Oracle Fusion Data Security grants. A grant can specify entitlement to the following.
Specific rows of data (data object) identified by primary key
Groups of data (instance set) based on a predicate that names a particular parameter
Data objects or instance sets based on runtime user session variables
Data is either identified by the primary key value of the row in the table where the data is stored. Or data is identified by a rule (SQL predicate) applied to the WHERE clause of a query against the table where the data is stored.
Oracle Fusion Data Security can be used to restrict the following.
Rows that are returned by a given query based on the intended business operation
Actions that are available for a given row
Grants control which data a user can access.
Note
Attribute level security using grants requires a data security policy to secure the attribute and the entitlement check enforces that policy.
A grant logically joins a user or role and an entitlement
with a static or parameterized object instance set. For example, REGION='WEST'
is a static object instance set
and REGION=&GRANT_ALIAS.PARAMETER1
is a parameterized object instance set. In the context of a specific
object instance, grants specify the allowable actions on the set of
accessible object instances. In the database, grants are stored in
FND_GRANTS and object instance sets are stored in FND_OBJECT_INSTANCE_SETS.
Object access can be tested using the privilege check application
programming interface (API).
A business object is a logical entity that is typically implemented as a table or view, and corresponds to a physical database resource. The data security policies of the security reference implementation secure predefined database resources. Use the Manage Data Security Policies task to define and register other database resources.
Data security policies identify sets of data on the registered business object and the actions that may be performed on the business object by a role The grant can be made by data instance, instance set or at a global level..
Note
Use parameterized object instance sets whenever feasible to reduce the number of predicates the database parses and the number of administrative intervention required as static object instances sets become obsolete. In HCM, security profiles generate the instance sets.
A data security policy applies a condition and allowable actions to a database resource for a role. When that role is provisioned to a user, the user has access to data defined by the policy. In the case of the predefined security reference implementation, this role is always a duty role. Data roles generated to inherit the job role based on data role templates limit access to database resources in a particular dimension, such as the US business unit.
The database resource defines and instance of a data object. The data object is a table, view, or flexfield.
The following figure shows the database resource definition as the means by which a data security policy secures a data object. The database resource names the data object. The data security policy grants to a role access to that database resource based on the policy's action and condition.
A database resource specifies access to a table, view, or flexfield that is secured by a data security policy.
Name providing a means of identifying the database resource
Data object to which the database resource points
Data security policies consist of actions and conditions for accessing all, some, or a single row of a database resource.
Condition identifying the instance set of values in the data object
Action specifying the type of access allowed on the available values
Note
If the data security policy needs to be less restrictive than any available database resource for a data object, define a new data security policy.
Actions correspond to privileges that entitle kinds of access to objects, such as view, edit, or delete. The actions allowed by a data security policy include all or a subset of the actions that exist for the database resource.
A condition is either a SQL predicate or an XML filter. A condition expresses the values in the data object by a search operator or a relationship in a tree hierarchy. A SQL predicate, unlike an XML filter, is entered in a text field in the data security user interface pages and supports more complex filtering than an XML filter, such as nesting of conditions or sub queries. An XML filter, unlike a SQL predicate, is assembled from choices in the UI pages as an AND statement.
Tip
An XML filter can be effective in downstream processes such as business intelligence metrics. A SQL predicate cannot be used in downstream metrics.
You use data role templates to generate data roles. You generate such data roles, and create and maintain data role templates in the Authorization Policy Manager (APM).
Note
HCM data roles are generated using the Manage Data Roles and Security Profiles task, which uses HCM security profiles, not data role templates, to define the data security condition.
The following attributes define a data role template.
Template name
Template description
Template group ID
Base roles
Data dimension
Data role naming rule
Data security policies
The data role template specifies which base roles to combine with which dimension values for a set of data security policies. The base roles are the parent job or abstract roles of the data roles.
Note
Abstract, job, and data roles are enterprise roles in Oracle Fusion Applications. Oracle Fusion Middleware products such as Oracle Identity Manager (OIM) and Authorization Policy Manager (APM) refer to enterprise roles as external roles. Duty roles are implemented as application roles in APM and scoped to individual Oracle Fusion Applications.
The dimension expresses stripes of data, such as territorial or geographic information you use to partition enterprise data. For example, business units are a type of dimension, and the values picked up for that dimension by the data role template as it creates data roles are the business units defined for your enterprise. The data role template constrains the generated data roles with grants of entitlement to access specific data resources with particular actions. The data role provides provisioned users with access to a dimensional subset of the data granted by a data security policy.
An example of a dimension is a business unit. An example of a dimension value is a specific business unit defined in your enterprise, such as US. An example of a data security policy is a grant to access a business object such as an invoice with a view entitlement.
When you generate data roles, the template applies the values of the dimension and participant data security policies to the group of base roles.
The template generates the data roles using a naming convention specified by the template's naming rule. The generated data roles are stored in the Lightweight Directory Access Protocol (LDAP) store. Once a data role is generated, you provision it to users. A user provisioned with a data role is granted permission to access the data defined by the dimension and data security grant policies of the data role template.
For example, a data role template contains an Accounts Payable Specialist role and an Accounts Payable Manager role as its base roles, and region as its dimension, with the dimension values US and UK. The naming convention is [base-role-name]:[DIMENSION-CODE-NAME]. This data role template generates four data roles.
Accounts Payable Specialist - US (business unit)
Accounts Payable Specialist - UK (business unit)
Accounts Payable Manager - US (business unit)
Accounts Payable Manager - UK (business unit)
If you add a base role to an existing data role template, you can generate a new set of data roles. If the naming rule is unchanged, existing data roles are overwritten.
If you remove a base role from a data role template and regenerate data roles, a resulting invalid role list gives you the option to delete or disable the data roles that would be changed by that removal.
If you add a dimension value to your enterprise that is used by a data role template, you must regenerate roles from that data role template to create a data role for the new dimension. For example if you add a business unit to your enterprise, you must regenerate data roles from the data role templates that include business unit as a dimension.
If you add or remove a dimension value from your enterprise that is used to generate data roles, regenerating the set of data roles adds or removes the data roles for those dimension values. If your enterprise has scheduled regeneration as an Oracle Enterprise Scheduler Services process, the changes are made automatically.
For information on working with data role templates, see the Oracle Fusion Middleware Administrator's Guide for Authorization Policy Manager (Oracle Fusion Applications Edition).
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 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, and payroll flow 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.
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.
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
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 manager's 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 Payroll Flows |
Payroll Flow |
Identifies all payroll flows 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.
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.
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.
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.
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
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.
You can create users by entering basic person and employment data. A user account is created automatically for a person when you create the user record. You can assign the users Oracle Fusion Human Capital Management (HCM) and non-HCM data roles, each providing access to specific functions and data. This example demonstrates how to create a user and assign roles to the user.
Note
This user management functionality is available for HCM Foundation and Oracle Fusion Workforce Directory Management (WDM) users only.
Decisions to Consider |
In this Example |
---|---|
For whom are you creating the user record? |
Gail Williams |
What is the user account name? |
Same as the e-mail ID, gail.williams@vision.com |
Where is Gail employed? |
Gail is an employee of Vision Corporation, and works in the Human Resources (HR) department in the Canada office. |
What roles must be provisioned to Gail? |
Autoprovision the employee role. Gail is responsible for processing workers' expense claims so provision the role Expense Claims Administrator manually to Gail. |
Attribute |
Value |
---|---|
System Person Type |
Employee |
Assignment Status |
Active |
In the role mapping you include the:
Employee role, and select the Autoprovision option
Expense Claims Administrator role, and select the Self-requestable option
Field |
Value |
---|---|
Last Name |
Williams |
First Name |
Gail |
|
gail.williams@vision.com |
Hire Date |
4/12/11 |
Field |
Value |
---|---|
Legal Employer |
Vision Corporation |
Business Unit |
Vision Canada |
Department |
Human Resources |