Explain Security Model: Authentication & Authorization in Oracle BI

5 / 55

OBIEEintermediate

Security Model: Authentication & Authorization

Distinguish authentication (who you are) from authorization (what you can see/do) in OBIEE, and how Application Roles, groups, and RPD security tie together.

Two questions, answered in different places.

It's like a building badge system: reception (WebLogic) checks your ID and knows which department you're in; your badge (Application Role) then decides which floors (subject areas) the elevator will even show you, and which filing cabinets (rows of data) on that floor you're allowed to open.

Key Concepts

    authentication   who are you?        WebLogic / the identity store
    authorization    what may you see?   Application Roles, catalog
                                         permissions, RPD data security

Authentication is delegated. WebLogic's security realm is backed by its embedded LDAP, an external LDAP or Active Directory, or single sign-on through SAML, Kerberos or Oracle Access Manager.

OBIEE does not hold passwords in a production deployment. The identity store does.

Then the mapping. The user authenticates, WebLogic issues a subject with their group memberships, and OPSS maps those groups to Application Roles.

    AD group "Sales Managers"
        -> Application Role "SalesManager"

Application Roles are the unit everything else grants to. Not users, and not LDAP groups directly:

    catalog permissions   granted to Application Roles
    RPD data security     written against Application Roles
    RPD object security   which subject areas a role can see

So adding somebody to an AD group gives them the role, and the role already has everything. No OBIEE change is needed for a new joiner, which is the point of the indirection.

Three layers of authorization, and they are separate.

    object security (RPD)   can you see this subject area or column
    catalog permissions     can you open this dashboard
    data security (RPD)     which rows do you get

A user can pass the first two and see an empty report because of the third. That is not a fault; it is three controls doing three jobs.

Row-level security is a filter in the RPD.

    Application Role "IndiaSales"
      filter on Sales: Region = 'IN'

Applied by the BI Server when it generates SQL, so it cannot be bypassed by any analysis. Session variables make it dynamic — a filter of Region = VALUEOF(NQ_SESSION.USER_REGION), with the variable initialised from a query at login.

Region = VALUEOF(NQ_SESSION.USER_REGION)

Which is why the initialisation block matters. If that query returns nothing for a user, the variable is empty, and depending on the filter they see either nothing or everything. The second is the dangerous case, and it is why such filters are written to fail closed.

What the interviewer is probing.1. "How does OBIEE authenticate and authorise?" Probing: the model. Stalls: "A login." Moves up: authentication through the WebLogic identity store or an external directory, with authorisation through application roles mapped to groups.

2. "What is the difference between object and data security?" Probing: the distinction. Stalls: "Nothing." Moves up: object security controls access to subject areas, columns and catalog objects; data security filters rows through the RPD.

3. "How is row-level security implemented?" Probing: the practical mechanism. Stalls: "In the query." Moves up: data filters on application roles in the RPD, usually driven by a session variable initialised from the logged-in user.

4. "Why put the filter in the RPD rather than the analysis?" Probing: the argument. Stalls: "It is easier." Moves up: an analysis filter can be removed by the user; an RPD filter applies to every query including ad-hoc and BI Publisher.