Security and User Management
Layers of security
Oracle BI security operates at several levels that must agree. Authentication verifies identity, often delegated to an external directory or single sign-on. Authorization decides what a user may see, enforced through repository privileges (which presentation objects and subject areas are visible) and catalog permissions (which folders and objects are accessible). Data-level security restricts rows using filters or session variables, and object-level security restricts columns and tables. Users are organized into application roles, and roles are granted privileges.
Session variables and initialization blocks
Session variables carry per-user values such as region or user ID into queries, enabling row-level filtering. They are populated by initialization blocks, which may run a query or read from a directory. A common pattern: an initialization block queries a user-to-region mapping table and sets a session variable used in a logical column filter. Repository variables are shared and refreshed on a schedule; session variables are per-user.
Traps to watch
A classic trap is mixing repository and session variables - repository variables are global, session variables are per-user. Another is assuming catalog permissions override repository privileges: both must permit access. Questions may test that application roles, not individual users, receive privileges, and that data-level filtering via session variables happens in the BI Server, not the database alone. Also remember that hiding a column in presentation does not substitute for proper role-based security.
Rule of thumb
For row-level questions, look for a session variable populated by an initialization block and referenced in a filter. For access questions, check both repository privileges and catalog permissions.