Tag Archives: security profile

Oracle Fusion Application Security Overview

Oracle fusion application security mechanism is designed on the base of role-based access control (RBAC). Oracle recommend to implement roles with functional security and data security and then assign roles to user, which bring benefits from maintenance and reusability. We should not directly assign functional security and data security to user, even though it looks ok from technical perspective.

First, let’s have a look at the Oracle recommended security setup process with a real business scenario, and then have a review of Oracle fusion security architecture and concept for further understanding.

Oracle recommended Security Setup Process, which is the most safe for your implementation.

Considering you have a financial manager called Ning  Yun, who is responsible for all financial modules as a manager role in business unit A, B, C, Ledger X, Y, and asset book Z.

1. Create a user ning with person information (generally employee information). A person will auto created in HCM. Or you can create person in HCM and user will be auto created.

2. You should have had job roles, like general ledger manager, payables manager, receivables manager, etc. in your system, generally they are predefined by oracle.

3. Create data roles for above job roles through data role template. Or the data role can be generated automatically when you create BU, asset book, GL data access set.

4. Assign the necessary data role to user.

I recommend that you always generate data role by data role template or generate automatically and NOT try to generate your own data security, because it is not completed. If you try to research the Oracle-predefined data role template, it is very complex. You can duplicate it by data security easily. So, always use data template or auto generation.

 

Oracle fusion security architecture and concepts

Functional Security:

1. Resource: Very technical concept that the technical components used by privilege.

2. Entitlement (Privilege): A task/action of duty role. An entitlement is one or more allowable actions applied to a set of database resources.

3. Application Role (Duty/Duty role):  Duty roles cannot be provisioned directly to users, but are inherited by enterprise roles to control access to applications. Duty roles may carry both function and data security grants.

4. External Role (Job/Job role): Specific to a job, and controls access to functions through inherited duty roles that carry the entitlement necessary for performing specific tasks associated with the duties of the job, such as access for a procurement manager.

5. User: application user registered in system.

Data Security

6. Database resource:  A database resource specifies access to a table, view, or flexfield that is secured by a data security policy.

7. HCM Security Profile: HCM data roles are generated using the Manage Data Roles and Security Profiles task, which uses HCM security profiles, not data role templates, to define the data security condition.

8. Data role template: You use data role templates to generate data roles. You generate such data roles, and create and maintain data role templates in the Authorization Policy Manager (APM).

Data Role (Also external role in APM): Specific to a job within a dimension of data, and augments the inherited abstract, duty, or job roles with entitlement to access specific data, such as access for a procurement manager in a particular business unit. Job role with data security.

image

 

Example:

External Role/Job Role: Accounts Payable Manager (which is mapping to real AP manager in business)

Duties assigned directly and indirectly to the job role Accounts Payable Manager

Application Role/Duty Role

Description

Accounts Payable Managerial Analysis Duty: Analyzes Invoices and related documents along with Payments, Holds  Discounts, and Payables Balances

Accounts Payable Period Status Management Duty: Manages Oracle Fusion Payables period status.

Accounts Payable Period Status Review Duty: Reviews Oracle Fusion Payables period status.

Actual Procurement Cost Collection Duty: Subscribes to costing service for interfacing invoice transactions to receipt accounting.

……

The relationship between external role (data role) and job role: (first page for functional hierarchy, second page for data security)

image

image

 

The relationship between job role and application rule:

image

The relationship between application role and entitlement:

image

The relationship between entitlement and resource:

image

(From my own opinion, the security mechanism, especially data security is very complex in current version of Fusion Application, so please always use data role template or auto-generation. That’s enough)

Differences between HR:Security Profile & MO:Security Profile

HR:Security Profile and MO:Security Profile are used for MOAC (Multi-Org-Access-Control).
HR:Security Profile is used to restrict the data in Human Resources according to the Business Group or whatever criteria you define in this security profile. Thus, for HR, it uses this secuity profile in its data exposure to the user.
MO:Security Profile acts the same but is used for Financials and Manufacturing applications. It restricts the access (site level or can be set at responsibility level) to certain operating unit (or whatever criteria defined in the security profile).
If there is no value at MO:Security Profile, then Financials and Manufacturing use the HR:Security Profile option for their data exposure to users.

Multi-Org features in Oracle EBS 11i and R12

Generally, Oracle 11i fulfills multi-org feature by the views in apps schema; while Oracle R12 fulfills the feature by Virtual Private Database feature.

In 11i,  the base table are created by product schema, e.g. oe_order_headers_all in ont db schema. In apps schema, there’s a view called oe_order_headers, which has a where clause like “org_id = SUBSTRB (USERENV (‘CLIENT_INFO’), 1, 10)” . So every user accessed application has his own userenv, then every user can access his own org’s data.

In R12, the base table are also created by product schema, e.g. oe_order_haders_all in ont schema. In apps schema, there’s a Synonym oe_order_headers with VPD feature to fulfill the multi-org feature.

In 11i, we set MO: Operating Unit profile on the responsibility level, then all of user logged from this responsibility has this OU(org_id) client info, so this user can only access this operating unit data from this responsibility.

In R12, we set up a security profile, which can include several operating units, then we assign this security profile to the profile option “MO: Security Profile” on the responsibility level.  The user logged from this responsibility can access all of OUs’ data  in the security profile.