Fusion Applications Security

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/External Roles – Maintained in OIM
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

Applications Roles – Maintained in APM
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.

If you are creating a custom role. then First you create external role in OIM and then create custom Application Role in APM and map external role to the application role in External Role Mapping Tab as shown below

External Role Mapping

Alternatively you can also map application role to the external role in APM as shown below under application role mapping. You need to first inquire the external role and then map the application role.

Application Role Mapping






Account Hierarchy

Hierarchies for financial reporting: Must be published to Essbase cubes. Child values in these hierarchies cannot roll up to different parents within a hierarchy as this functionality is not support when publishing such hierarchies to Essbase.
Hierarchies for allocations: Must be published to Essbase cubes. Used with Calculation Manager in creating allocation rules.
Hierarchies for cross validation rules, revaluation, Data Access Set and chart of accounts mapping:

  • Created within the same hierarchy and must be associated with a chart of accounts instance.
  • You can only associate one hierarchy with a chart of accounts instance, per segment.
    Such hierarchies can have the same child to roll up to different parents.
  • Do not publish to the Essbase cube since multiple child assignments are not supported in the Essbase cube.
  • NOTE: these hierarchies will not be available for reporting and allocations.
  • Only the tree assigned to the segment in COA definition will be displayed in the DAS UI.
  • Make sure to perform Column and Row Flattening for these hierarchies.

Security Rules: You can specify the tree and tree version to be used while defining the data security condition.