Explain Fusion Security Model: Roles and Data Security in Oracle Applications

24 / 60

Fusionadvanced

Fusion Security Model: Roles and Data Security

Explain Oracle Fusion's role-based access control model and how it differs from EBS's responsibility model

EBS grants a responsibility. Fusion layers four kinds of role, and separates what you can do from what you can see.

Fusion's security model is like a hospital's staff badge system: a badge (job role) is built from specific certified skills (duty roles) like 'can administer medication', and separately, the hospital's records system restricts which patients' charts (data security) that badge can open based on which ward the staff member is assigned to — function access and data access are governed independently but combined at the point of use.

Key Concepts

The four role types, from smallest up.

    Duty role      one task: "Invoice Entry Duty"
    Job role       a real job: "Accounts Payable Specialist",
                   built from duty roles
    Abstract role  a status rather than a job: "Employee",
                   "Line Manager"
    Data role      a job role scoped to specific data:
                   "AP Specialist - India BU"

Function security and data security are different questions.

    function security   which pages and actions -- from duty roles
    data security       which rows -- from data security policies

A user can hold "Accounts Payable Specialist" and see no invoices at all, because the data security policy does not grant them any business unit. The page loads and is empty, which is the Fusion equivalent of the MOAC problem in EBS.

A data security policy joins three things: a role, a database resource, and a condition. The condition is usually a security profile — which business units, which ledgers, which departments.

Role mappings provision automatically, and this is the substantial improvement over EBS.

    condition:  job = 'AP Specialist' AND business unit = 'India'
    assigns:    the AP Specialist Data Role for India BU

A new hire's HR record is created, the mapping matches, and the access appears. When they change job, the old role is removed and the new one granted by the same mechanism.

In EBS that was a person assigning responsibilities by hand, and the failure mode was access that nobody removed when someone moved on.

Never modify a seeded role. Copy it and extend the copy.

Seeded roles are replaced at quarterly updates. A modified one is either overwritten — losing your change silently — or blocks the update. A copy is yours and survives.

Building a custom role means assembling existing duty roles rather than starting from nothing. The duty roles already map to the correct function security, and getting that right by hand is not realistic.

The debugging path when someone cannot see something: is it function security (the page or button is absent) or data security (the page is there and empty)? Those have different causes and different fixes, and telling them apart is the first step.

What the interviewer is probing.1. "Describe the role hierarchy." Probing: the model. Stalls: "Roles." Moves up: job roles contain duty roles which carry privileges, with abstract roles covering what everyone needs and data roles scoping the data.

2. "What is the difference between function and data security?" Probing: the distinction. Stalls: "Nothing." Moves up: function security decides what you can do; data security decides which records you can do it to, through security profiles.

3. "Why should you never modify a delivered role?" Probing: the discipline. Stalls: "You can." Moves up: updates overwrite it — you copy it into a custom role and change that.

4. "How do you find out why a user cannot see data?" Probing: the practical skill. Stalls: "Add a role." Moves up: the security console role hierarchy and the data security policies on the relevant object, rather than granting a broader role.