Intro
Security is the most complex and important requirement that is considered by all customers. It gets even more important in the cloud environment. In this post I’d like to share my experience about Fusion Applications security concepts and a new tool (Security Console) that helps users to setup access to the system easier.
To tell the truth I was a little bit confused when I started to learn Fusion Applications Security concepts and found out that identity and access management subsystem is external and separated from business application. In the most all old ERP applications I have worked with security was incorporated in a system core (SAP HCM, Oracle E-Business Suite). But there were also new web applications that had a dedicated security subsystem. Those systems like Taleo, Hyperion were based on a Service-Oriented Architecture (SOA).
Later I realized that it makes sense and a dedicated security model is optimal for SOA applications. That’s why oracle development team brought this approach in Fusion Applications. It also confirms oracle’s statement that Oracle Fusion Applications combine the best of the Oracle business applications Oracle currently provides.
Fusion Applications Security Concepts
Fusion Applications Security is designed based on Role-Based Access Control (RBAC). It is an approach to restricting access to authorized users. Oracle Fusion Applications uses four types of roles for security management:
- Data Roles
- Abstract Roles
- Job Roles
- Duty Roles
Data role is a combination of a employee’s job and the data instances that users with the role need to access. They aren’t delivered as part of the Security Reference Implementation but are always locally defined. They are assigned directly to users.
Abstract roles represent a employee’s role in the enterprise, independently of the job that the worker is hired to do. Three abstract roles are delivered with Oracle Fusion HCM. These are the Employee, Line Manager, and Contingent Worker roles. You can create custom abstract roles. You assign abstract roles directly to users.
Job roles align with the job that a worker is hired to perform. (e.g. Human Resource Analyst). You can create custom job roles. Typically, you include job roles in data roles and assign those data roles to users.
Duty roles:
- Align with the individual duties that users perform as part of their job.
- Grant access to work areas, dashboards, task flows, application pages, reports, batch programs, and so on.
- May carry both function and data security grants.
- Are inherited by job and abstract roles, and can also be inherited by other duty roles.
- Are delivered as part of the Security Reference Implementation, and can be used as building blocks of custom job and abstract roles.
- Are not assigned directly to users.
Data Security Policies
Each data security policy combines:
- The role to which the data security policy is granted.
- A business object that’s being accessed. (e.g. HR_ALL_POSITIONS_F table)
- The condition, if any, that controls access to specific instances of the business object. Conditions are usually specified for resources that you secure using HCM security profiles. Otherwise, business object instances can be identified by key values.
- A data security privilege that defines permitted actions on the data
Function Security Privileges secure the code resources that make up the relevant pages, such as the Manage Jobs and Manage Positions pages. Some user interfaces aren’t subject to data security, so some function security privileges have no equivalent data security policy.
The following table shows security component terminology comparison with Oracle E-Business Suite:
Fusion Applications |
E-Business Suite |
Data Role, Abstract Role |
Responsibility |
Job Role |
Top-Level Menu |
Duty Role |
Submenu |
Privilege |
Form Function |
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) subsystem. The IDM subsystem 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
Release 10 Simplified Reference Role Model
In fact previous security model (Before Release 10) was very complicated. There were too many duty roles associated to a Job Role and it was very difficult to customize job roles. Although Security Console has been released in Release 9 there was difficult to use it with old security model. Starting with Release 10, you receive a new, simplified reference role for each predefined job and abstract role that existed in the previous release. Also Oracle strictly recommends to upgrade your Fusion Applications instance to the Simplified Reference Role Model before migration to upcoming Release 11. Fore details please see the following MOS Note: Upgrading Applications Security in Oracle HCM Cloud Release 10 (Doc ID 2023523.1)
The main benefit of the simplified reference role model is that it has fewer role levels. It’s a flatter model.
On the following screenshots you can see the role Line Manager before and after upgrade:
Before:
After:
After updating Job, Abstract roles you should:
- Update Security Profiles, connected with updated roles
- Run the process Import User and Role Application Security Data – process copies the data from LDAP to Fusion HCM Security Console tables.
You shouldn’t customize reference roles after upgrade. You should use Security Console instead to make copy from reference roles and then provide needed customization.
Security Console
The Security Console is a single administrative interface, available from the springboard on the simplified user interface, from where you can:
- Create custom job and abstract roles.
- Copy and edit job, abstract, and duty roles.
- Compare roles of all types to identify differences.
- View the roles assigned to a user, and identify users who have a specific role.
- Review role hierarchies.
- Review the Navigator menu and work-area task-pane entries for a user or role.
- Manage X.509 and PGP certificates.
Before start to use Security Console within HCM module you have to complete two setup steps:
- Set profile options ASE_WORKING_APP_STRIPE = hcm (hcm is default, so you can leave it blank), ASE_ROLE_MGMT_PREF = Yes.
- Schedule the process Import User and Role Application Security Data (recommended to run periodically at least 2 times a day).
I try to stick to the following rules when I create custom Job or Abstract Roles within Security Console:
1. Find a proper model
2. Make a copy from a Duty Role
3. Customize a copy according to the requirements
4. Create a custom Job or Abstract Role and assign the Duty created in the previous step
5. Assign a new role to a user
6. Run Retrieve latest LDAP Changes Process
7. Create needed Security Profiles and Assign to a custom role
8. Check a user and make corrections if needed
Hope this helps.
I would like to wish you a Merry Christmas and Happy New Year!!!
And remember:
“If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.” ~ George Bernard Shaw
Kind Regards,
Volodymyr
Wonderful article, thanks a lot for sharing it.
Can i do the same with PO or Expense in Rel 11?
Yes you can
Hi Volodymyr,
I wanted to understand the user identity and role data synchronization process.
Does this mean that when a user is created in HCM it can be automatically created in the on prem identity management system/ LDAP directory such as MS Active Directory? If not what LDAP server is being to referred in the documentatins. If it is the on prem LDAP (OID / AD) where is the configuration done to make sure that a bi directional synchronization of user identities and roles can achieved which us one of the key requirements for Single Sign to work.
Cheers,
Kuntal