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