Oracle Fusion Applications Security Guide

Role-based access control (RBAC) normalizes access to functions and data through user roles rather than only users. User access is based on the definition of the roles provisioned to the user.

RBAC secures access in a "Who can do what on which functions or sets of data under what conditions" approach. The "who" is the user.

The "what" are the abstract operations or entitlement to actions applied to resources. For example, view and edit are actions, and task flows or rows in data tables are resources.

Entitlement secures access rights to application functions and data. Function access entitlement is granted explicitly to duty roles. This implicitly grants the function access to the job and abstract roles that inherit the duty roles. Data access entitlement is granted implicitly to abstract and job roles through data security policies on their inherited duty roles. Data access entitlement is granted explicitly to a data role through a data security policy applied directly to the inherited job or abstract role.

The following figure shows the implicit and explicit access entitlements of the role types. The Accounts Payable Manager: USA grants explicit access to Payables Invoices in the USA data dimension. The Sales Party Review Duty role grants access to Sales Party data. A Marketing Analyst includes the Sales Party Review Duty role in its hierarchy, which provides the Marketing Analyst with implicit access to the Sales Party data. A data security policy states that a Marketing Analyst can view sales party where user is in the management chain of a resource who is on the sales account team.

In the security reference implementation, an example of a data role generated by a predefined data role template in an enterprise with a business unit named US is an Accounts Payable Manager - US role that inherits the Accounts Payable Manager job role. The data role grants explicit access to Payables Invoices in the US data dimension.

An example of a duty role is the Sales Party Review Duty role, which grants access to Sales Party data. Another example of a job role is the Marketing Analyst role, which includes the Sales Party Review Duty role in its hierarchy. The Sales Party Review Duty role provides the Marketing Analyst with implicit access to the Sales Party data. A data security policy states that a Marketing Analyst can view sales party information where user is in the management chain of a resource who is on the sales account team.

An example of an abstract role is the Employee role, which inherits duty roles that entitle access to functions and data belonging to tasks performed by all employees, such as entering requisitions.

As a security guideline, grants are made to duty roles, and duty roles are given as children to job or abstract roles. Grants are also made to data roles.

The figure shows how grants include sets of entitlement that capture the access and action rights of a duty role.

Explicit Access

An explicit entitlement names the specific function or data that the holder of the entitlement is authorized to access.

Only duty roles hold explicit entitlement to functions. An entitlement to a function allows one or more actions, such as update, create, and view applied to a resource, such as a task flow.

Data roles hold explicit entitlement to data. Data roles are entitled access to functions through inherited role hierarchies. Data roles are entitled access to data through conditional grants on each object. In most cases, the data you secure in your enterprise is secured with data roles.

In the following example, the user provisioned with a data role carries explicit access specifically to the US business unit dimension of data relevant for an accounts payables specialist.

Implicit Access

An implicit entitlement names roles to which explicit entitlement is granted through a role hierarchy.

Abstract, job, and data roles have implicit access to functions through duty roles that they inherit. Abstract, job, and duty roles have implicit access to data through data security policies. Data is also secured implicitly with the underlying data model of the product family records, which contain all the information required to enable Oracle Fusion data security. For example: A person assigned to a task is recorded in a project table, and the data in the record drives the security on that data. No provisioning is required to enable project team access. Typically a business event is raised that enables a human workflow approval of the action.

Implicit data access is easier to manage and maintain than explicit data access, but not available when requirements can only be met using explicit data access.

In the following example, the user provisioned with a job role carries implicit access through a role hierarchy with duty roles that participate in data security policies defining access to data required for performing the duties of that job.

User With Multiple Roles

A user who fills multiple roles in the organization should be provisioned with multiple roles for security reasons so changes in responsibility can be quickly applied. The user's functional and data access is the union of grants provided by the provisioned roles.

For example, a user can be provisioned with the Benefits Specialist, Human Resources Specialist, and Line Manager roles. These roles grant different, though partially overlapping, functional access, and differing data access.

One role gives the user access to one subset of functions and data, while another role gives access to another subset. For example, in Human Capital Management (HCM) the human resources (HR), payroll, and benefits roles carry entitlements to access different parts of a process. For example, a human resources specialist, a line manager, and an employee can perform the following tasks.

Role Types : How They Fit Together

Oracle Fusion Applications security provides abstract, job, data, and duty roles that work together to control access to functions and data.

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.

Abstract roles identify a general association to the enterprise or organization, such as employee or line manager. Job roles reflect job titles and describe positions of responsibility, such as Payables manager or buyer. Data roles identify entitlement to access specific data. Duty roles group tasks that must be performed within an abstract or job role.

Oracle Fusion Applications record abstract, job, and data roles as enterprise roles shared across multiple applications and instances of applications. Duty roles function at the application level and are a grouping of tasks to be done within an abstract or job role.

Abstract and job roles must inherit duty roles. Job roles may inherit abstract roles and other job roles. Data roles may inherit abstract, job, and other data roles. Duty roles may inherit other duty roles. The figure shows these inheritance relationships among role types.

For example, a data role defined as Accounts Payable Manager - US inherits the job role Accounts Payable Manager. The job role Accounts Payable Manager inherits the duty role Approving Payable Invoices Duty and the abstract role Line Manager.

Note

In the reference implementation, the Payables Manager does not inherit the Line Manager role. This example represents an enterprise specific modification to the reference implementation.

Provisioning

You provision enterprise roles to users. Enterprise roles inherit a hierarchy of roles. Application roles are not directly provisioned to users. When you initiate a provisioning event in Oracle Fusion Applications you invoke Oracle Identity Management.

Where data roles are available, they should be provisioned rather than provisioning the job roles they inherit.

Role Hierarchy

Roles form hierarchical groups. Entitlement can be inherited from one or more child roles in a role hierarchy. You manage role hierarchies in APM.

Adding roles to a hierarchy may introduce segregation of duties policy violations by authorizing a provisioned user with access that can lead to deliberate or inadvertent fraud.