Wednesday, September 27, 2017

Oracle Fusion Roles Concepts in Fusion Applications

Introduction to Fusion Applications Roles Concepts

Fusion Applications Security is designed based on Role-Based Access Control (RBAC). It is an approach to restricting access to authorized users. In general, RBAC is defined based on the primary rules as per this wiki page.
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 roles are defined at functional and technical levels. The functional level is the business definition that is used by business users and the technical level is the implementation of roles using Oracle Technology. This post will quickly review the definition of “Functional Roles” and provide introductory internals on the technical implementation of these “Roles” within Fusion Applications.

Architecture of Functional Roles


At a high level, RBAC is based on the following concepts:

·         Role assignment: A subject can exercise permission only if the subject has selected or been assigned a role.
·         Role authorization: A subject’s active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
·         Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.
In Fusion Applications, the RBAC implementation is based on abstract, job, duty, and data roles that work together to control access to functions and data. The definitions of these functional roles are as follows:

Abstract Role:

This role categorizes the roles for reference implementation. It inherits duty role but does not contain security policies. For example: Employee, Manager, etc.

Job Role:

This role defines a specific job an employee is responsible for. An employee may have many job roles. It may require the data role to control the actions of the respective objects. For example: Benefits Manager, Accounts Receivable Specialist, etc.

Data Role:

This role defines access to the data within a specific duty. Who can do what on which set of data? The possible actions are read, update, delete, and manage. Only duty roles hold explicit entitlement to the data. These entitlements control the privileges such as in a user interface that can see specific screens, buttons, data columns, and other artifacts.

Duty Role:

This role defines a set of tasks. It is the most granular form of a role. The job and abstract roles inherit duty roles. The data security policies are specified to duty roles to control actions on all respective objects.
This is a diagram from the “Oracle Fusion Applications Security Guide” that shows the relationships between these roles:



Note: The duty role in above diagram is the granular form of a role where security policies are attached. They are implemented as application roles in APM and scoped to individual Oracle Fusion Applications.


Please provide your valuable feedback ............