Introduction
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:
![rolediag]()
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.
Technical Implementation of Functional Roles
The above functional roles are technically implemented as Enterprise and Applications roles. The Abstract, Job and Data roles are called Enterprise roles and the Duty role is called Application role.
Fusion Applications implements the security using the Oracle Identity Management (IDM) stack. The IDM stack consists of identity store and Policy store . The Enterprise and Applications roles are implemented y in Identity and Policy stores respectively.
Enterprise Roles
Across all Fusion Applications, Abstract, Job and Data roles are mapped to Enterprise roles . These roles are stored in the Identity Store. They are managed through OIM and Identity Administration tools. This tool includes the following capabilities with respect to Enterprise role management:
- Create Fusion Applications Implementation Users
- Provision Roles to Implementation Users
- Manage Abstract, Job and Data roles including the job hierarchy
The predefined Abstract, Job and Data roles are seeded in:
cn=FusionGroups,cn=groups,dc=us,dc=<MyCompany>,dc=com
Example of Data Role: The role name ends with “_DATA ”. This is a naming convention and not a technical requirement.
cn=CN_INCENTIVE_COMPENSATION_MANAGER_FUSION_CORP_USA_DATA,cn=FusionGroups,cn=groups,dc=us,dc=oracle,dc=com
Example of Job Role: The role name ends with “_JOB”. This is a naming convention and not a technical requirement.
cn=BEN_BENEFITS_MANAGER_JOB,cn=FusionGroups,cn=groups,dc=us,dc=oracle,dc=com
Example of Abstract Role: The role name ends with “_ABSTRACT”. This is a naming convention and not a technical requirement.
cn=PER_EMPLOYEE_ABSTRACT,cn=FusionGroups,cn=groups,dc=us,dc=oracle,dc=com
These roles can also be viewed from ODSM (Oracle Directory Services Manager) console. The following steps illustrate this.
Login to ODSM and OID Connector; navigate from “Data Browser” tab as shown below.
![odsm1]()
Click on a role such as “BEN_BENEFITS_MANAGER_JOB”.
![Ben_benfits_mgr]()
Applications Roles
A “Duty Role” is mapped to Application Roles and is stored in the Policy Store. An application role is supplied by a single application or pillar of applications. The application policies are managed through “Authorization Policy Manager” (APM). APM is a graphical interface that simplifies the creation, configuration, and administration of application policies. Applications Authorization Policy Manager (APM) refers to enterprise roles as external roles. For more information on APM, please refer the following link.
Oracle Fusion Applications is certified to integrate with Applications Access Controls Governor (AACG) in the Oracle Governance, Risk and Compliance Controls (GRCC) suite to ensure effective segregation of duties (SOD). Oracle Fusion Applications checks duty roles for SOD policy violations measured against content and the risks defined in AACG and against content according to best available security guidelines. User and role provisioning respects the segregation of duties policies.
The following screen in APM UI shows Application Role mappings of External Role “Benefits Manager”:
![Ben_mgr_app_role]()
Through APM you can manage existing policies and respective privileges. You can also create new policies and privileges.The Application Roles are stored in Policy Store as:
cn=Roles,cn=<FAApp>,cn=FusionDomain,cn=JPSContext,cn=FAPolicies
Example to view “BENEFITS_REPORTING_DATA_DUTY” role from ODSM console:
Login to ODSM console, connect to OID and navigate from “Data Browser”.
![odsm_hcm]()
Expand HCM and navigate to “Roles” to see all the respective duties of HCM Applications.
![ben_rpt_data_duty]()
Fusion Applications Roles Provisioning Mapping
Fusion Applications uses FUSION.PER_USER_ROLES table to store information about what roles are provisioned to which users.
Example
User name: ORDER_MGR_OPERATIONS
select r.role_distinguished_name, p.role_GUID, u.username from per_user_roles p, per_roles_dn_vl r, per_users u where p.role_id=r.role_id and p.user_id = u.user_id and u.user_id = ‘118’
The output of the above query.
![per_user_roles_output]()
How all these roles and security policies/privileges work together?
Fusion Applications seeds all the relevant roles, though they can be modified and customized based on the business requirements. It is important to first understand the functional and data security policies.
Functional Security Polices
Function security consists of privileges granted to a user by means of the user’s membership in a role, to control access to a page or a specific widget or functionality/operation within a page, including services, screens, and flows, and typically used in control of the main menu. A function security policy consists of privileges assigned to duty roles and those duty roles assigned to a job or abstract role. Function security policies are defined in the Authorization Policy Manager (APM).
Function security is implemented using Java Authentication and Authorization Services (JAAS) permissions representing an Application Development Framework (ADF) artifact. These permissions are stored in the Oracle Platform Security Services (OPSS) policy store and are checked by ADF at runtime. When a user accesses the functions of a task flow, the OPSS policy store determines the access entitlement that applies to that user through the roles provisioned to the user.
Data Security Policies
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. 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 the application code
A privilege is a single, real world action on a single business object. The possible actions are read, update, delete, and manage. If these privileges are not specified on a duty or data role, then all actions on the respective objects within a page, including services, screens, and flows, and typically used in control of the main menu (specified by function policy) are allowed.
Enterprise roles provide access to data through data security policies defined for the inherited application roles. 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.
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.
Managing User and Roles relationships
These are the few major categories of managing and assigning roles to a user:
- Create a new user and apply existing roles as per business requirements.
- The business mandates a new role and respective policies/privileges. There are 3 major types:
- Create a new role but assign existing duties and generate data role.
- Create a new Duty and assign data security respectively. This new duty can be assigned to a new or existing user
- Create new Policies and Privileges . Assign theseit to new or existing Duty role.
The following is a quick example of how Enterprise and Application Roles works together to control access to functions and data.
A new Employee is hired as “Benefits Specialist”. The job role “Benefits Specialist” exists but this user should not have access to view salary data of all the enterprise users.The following screen shows all the duties a “Benefit Specialist” can perform:
![ben_specialist]()
One of the duty roles is “Benefits Salary Viewer Duty”. The following screen shows who else has this role:
![ben_salary_view_data]()
The following screen shows that no polices are assigned out of the box to “Benefits Salary Viewer Duty” role.
![ben_spec_salary]()
In order to add policy to “Benefits Salary Viewer” duty role to view salary data, let’s review the policies of “Salary Management” duty role. The following screen shows the functional policies assigned to this role:
![Snap20]()
To manage the above functional policy, select and click edit. The following screen shows how you can search entitlements such as “Salary” and select respectively as per business requirements.
![Snap21]()
The following screen show data security polices assigned to this role.
![Snap26]()
Select “Entry Salary Details” policy and click edit to open it.
![Snap27]()
Click on “Rule” tab to view the existing rules for this policy.
![Snap28]()
Click on “Action” tab to view selected actions (New action can be selected from available actions).![Snap29]()
The following screen is an example of data security policy that do not have access to view or manage salary data. In this case, the benefits specialist has been assigned another role policy “Party Information Inquiry Duty”. The data security for this policy is to view “Person” object only.
![party_info_inq_duty]()
The following screen is another example of data security policies that “Person Address View Duty” roles has to various resources/objects (another role assigned to benefits specialist).![per_addr_duty]()
If this new benefits specialist user should not have access to salary data, then the new role such as “Benefit Specialist without Salary View” can be created from an existing one with salary view role removed.
Conclusion
This post provides introductory information on functional roles and how they are technically implemented. It provides internals of how and where roles are stored respectively; and where and how they can be managed. Most importantly it provides how these roles work together for “Who can do what on which functions or sets of data under what conditions”. It also provides examples on how to manage functional and data policies.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission
