Our teammate Jack Desai published an article last year about Fusion Application Roles Concept. It gives you a great overview about the design to grant access to certain functionalities to specific users. His article familiarizes you with the concepts of Abstract Roles, Duty Roles, Job Roles or Data Roles and how they are used in a Role Based Access (RBAC) model in Fusion Applications.
Starting with the current Fusion Apps Release 10 further improvements in the role concept have been implemented resulting in flatter role hierarchies. More detailed information about the Simplified Reference Roles Models can be found in Oracle Support DocId 2016990.1.
The following article below will give a short introduction and overview about the changes and perform a brief comparison of features between role hierarchies in R10 and pre-R10.
As shown in the drawing below the main change is a simplification of complex structures in pre-R10 releases. For this purpose the old Duty Roles have been deprecated and replaced by newer versions with different and leaner assignments. These assignments can be other roles or even privileges. The previous model sometimes had many Duty Roles assigned to Job Roles. As a result creating custom Job Roles could become a challenge.
By introducing a simplified reference model the following benefits were achieved in R10:
The most visible aspect of the Release 10 simplification is the introduction of an Application Job Role and a reduced number of duty roles when compared to the role model in the previous release. Also worth to mention is that newly created Application Role Names start with a prefix “ORA_”.
As shown in figure above these changes in R10 include also an evolutionary process of modifications in terms of privilege assignments to duty and/or application roles. However the new role reference model doesn’t necessarily affect the setup details of these privileges (i.e. Entitlements, Resources etc). If there are changes for privileges in R10, theses might have been caused by functional and technical requirements in Fusion Application. Almost obvious to say that these changes in R10 are valid for entire Fusion Applications and work the same way for on-premise and Oracle Cloud instances.
When comparing the both role models we should start with the similarities between pre-R10 and R10 role models as they are:
As mentioned above the main differences are the hierarchical organization of roles under the Enterprise Job Role level. The figure below illustrates these changes for the sample of Sales Enterprise Job Role:
As shown in our sample below the Sales Representative Duty role exists for various application sources and could give the impression they refer to the same role as they are sharing almost the same display name in pre-R10 releases. In reality these are different roles! For instance the Sales Representative Duty role for CRM can be found under a role name ZBS_ENT_SALES_REPRESENTATIVE_DUTY while the role with same display name exists in HCM with the name ZBS_ENT_SALES_REPRESENTATIVE_DUTY_HCM.
In R10 we see that there are also Sales Representative roles assigned to Sales Representative Enterprise Role, but we notice the following differences:
As said the Application Job Role with the display name "Sales Representative" refer to the same role with name ORA_ZBS_SALES_REPRESENTATIVE_JOB across all Application Sources. Furthermore the usage of Role Categories has been introduced. These role category assignments put roles into a dedicated context and can be used for isolation in Cloud. In our sample the "Sales Representative" role is assigned to a Role Category named “CRM_ENTERPRISE_DUTY”. The Application Role Hierarchy might differ for roles with same names (like "Sales Representative") across the various Application Sources. For instance the "Sales Representative" role for HCM has the following Application Role Hierarchy assigned :
The same Application Job Role for FSCM contains a different Application Role Hierarchy used in that specific application context:
For a better illustration of differences between these both role models pre-R10 vs R10 sample screenshots of Fusion Apps Authorization Policy Management (APM) are shown below.
Starting point is the External Role “Channel Account Manager” in a pre-R10 instance with the internal name ZPM_CHANNEL_ACCOUNT_MANAGER_JOB as shown above. The screenshot below highlights the Application Role Mapping with various different Duty Roles assigned.
In R10 this External Role is unchanged (means: same name) but Application Role Mapping is different as shown in screenshot below. As mentioned previously there are Application Job Roles assigned in R10. Only a few duty roles for OBI are reused for technical reasons to provide continuity for some features. These are roles used by internal systems, such as role codes that end with _PRIV_OBI, which are used to secure reports. These roles don’t have the ORA_ prefix in the role code. You must never modify these roles.
In pre-R10 releases Duty Roles had the term “DUTY” included in internal name and also in display name (see screenshot below).
This role setup changes in R10 (below) as the prefix ORA has been added for newly created roles. As screenshot below indicates, the term JOB is added as suffix for Application Job Roles.
Another new feature is the assignment of Job and Duty Roles to specific Role Categories as shown below. The existing assignment is not to be changed by an user for standard roles.
As shown in the screenshot below the pre-R10 Duty Role has a dedicated layout in Application Role Hierarchy
In R10 the Application Role Hierarchy looks different as it has been reworked and flattened.
Duty Roles in R10 follow the name scheme with ORA as prefix and DUTY as suffix as shown below.
Policies assigned to these Duty Roles in R10 might be the same as those in pre-R10. Any changes between releases will have been caused by functional or technical requirements in various Application Sources during release changes (being done automatically when upgrading a certain release).
Screenshot below shows the detailed privileges (Entitlements) at the lowest level to grant access to pages, page flows, data or interfaces (all of then are called "Resources"). As said these structures are not affected in R10 by switching to a simplified role reference.
In case any custom job roles have been created in pre-R10 instances a migration to the simplified reference role model is necessary. As shown in the figure below the links to old duty roles must be removed and another link to the according Application Job Role in R10 created. Detailed instructions can be found in various documents under Oracle Support DocID 2016990.1.
This post provides an introduction to recent changes in the Role Model in R10. It is supposed to be seen in the context of the previous post about RBAC in Fusion Applications. Some more changes have been seen in R10 for security related topics and more posts on this site will follow to cover those.