OAC Security: Roles, Application Roles & Data Access

Explain how OAC's cloud-native security model (Identity Cloud/OCI IAM roles, Application Roles, and dataset-level access) compares to on-premise OBIEE security.

OAC keeps OBIEE's layered model and replaces the identity backend with a cloud identity service.

It's like a company that used to issue its own building badges (on-premise LDAP) now trusting a shared regional badge system (cloud IAM) that other tenants in the building also use — the badge still opens the right doors, but who issues and manages the badge itself has moved outside the company's own walls.

Key Concepts

    authentication   IDCS, or OCI IAM in current deployments
    authorization    Application Roles, as on-premise

The mapping chain is the same shape.

    user authenticates against IDCS / OCI IAM
      -> their groups are known
      -> groups map to OAC Application Roles
      -> roles carry permissions and data security

The predefined roles.

    BI Consumer        view content
    BI Content Author  create analyses and projects
    BI Data Load Author  upload datasets
    BI Service Administrator   administer the service

Custom roles are built on top, which is the same practice as on-premise: grant to roles, map groups to roles, and never grant to users.

What transfers from on-premise. The RPD's data security works unchanged — filters written against Application Roles, applied by the server, over subject areas.

So an organisation migrating brings its row-level security with it rather than rebuilding it.

What is new, and is the substance of the question. Self-service datasets have their own access model.

    a subject area   security defined centrally in the RPD
    a dataset        shared by the person who uploaded it

A user uploads a spreadsheet of salaries and shares a project built on it. Nothing in the RPD applies, because the RPD does not know about that file.

That is the governance gap self-service creates, and it exists in every tool of this kind. The controls are which users hold the data-load role, and whether datasets may be shared beyond their owner.

So the security conversation in OAC is not only "who can see which rows" but "who can bring data in", which did not arise in classic OBIEE because there was no way to.

The practical position. Give the data-load role deliberately rather than by default, point self-service at governed subject areas where possible, and treat uploaded datasets as content whose sharing needs the same review as the data they came from.

What the interviewer is probing.1. "How does OAC security layer up?" Probing: the model. Stalls: "Roles." Moves up: identity cloud service users and groups mapped to OAC application roles, which carry both functional permissions and data access.

2. "How is row-level security applied?" Probing: the mechanism. Stalls: "In the workbook." Moves up: through the semantic model with session variables, as in OBIEE — a workbook-level filter is not security.

3. "What is the self-service security gap?" Probing: the honest risk. Stalls: "None." *Moves up:* an uploaded dataset carries no row security, so a user can share data more widely than the governed model would allow.

4. "How do you control that?" Probing: the governance. Stalls: "Ban uploads." Moves up: limit who may upload and share, certify curated datasets, and audit what is being shared — rather than blocking self-service entirely.