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's security model preserves the layered authentication/authorization concepts from on-premise OBIEE but replaces the identity backend with cloud-native identity services, and interviewers ask about this specifically to see whether a candidate can translate on-premise security instincts to a cloud/SaaS context rather than assuming everything works identically.

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 in OAC is backed by Oracle Identity Cloud Service (IDCS) or, in more current OCI-native deployments, OCI Identity and Access Management (IAM) — users and groups are managed centrally in this cloud identity service (or federated from the customer's own corporate identity provider via SAML/SSO), rather than WebLogic's embedded LDAP as was common on-premise. Once authenticated, OAC maps identity provider groups to Application Roles (predefined ones like BI Service Administrator, BI Content Author, BI Consumer, plus custom roles), a concept directly analogous to on-premise OBIEE's Application Roles.

Oracle Identity Cloud Service (IDCS)OCI Identity and Access Management (IAM)Application RolesBI Service AdministratorBI Content Author

Data-level security has two coexisting models depending on the content type: for RPD-based subject areas (if the OAC instance still uses classic modeled content), row-level security works exactly as it does on-premise — data filters tied to Application Roles, session variables, VALUEOF() — because that's still fundamentally the same BI Server engine underneath. For self-service DV datasets, access control is typically managed at the dataset and project sharing level — who can view/edit a specific dataset or project — which is a coarser-grained model than RPD row-level filtering unless the dataset itself is built with row-level restrictions baked into its source query or via data access rules applied directly to the dataset.

RPD-based subject areasself-service DV datasetsdataset and project sharing leveldata access rulesVALUEOF()

A sharp interview point: because self-service datasets don't automatically inherit RPD-style row-level security, an OAC deployment that lets business users freely upload and share datasets needs a deliberate governance policy about what kinds of sensitive data are (and aren't) appropriate for self-service upload, since the fine-grained row-level protections a well-designed RPD provides don't automatically extend to every dataset a user creates.