Virtual Private Database (VPD): Predicate-Based Database Security

The correct answer is (iv) Virtual Private Database (VPD).

A Virtual Private Database allows a system administrator to associate a security-policy function with a table, view, or synonym—collectively, a protected database relation. The function returns a predicate that Oracle Database adds to queries accessing that relation.

For example, a policy function might return:

1department_id = 10

If a user submits:

1SELECT employee_id, salary
2FROM employees;

Oracle can internally enforce the equivalent of:

1SELECT employee_id, salary
2FROM employees
3WHERE department_id = 10;

The user’s original SQL does not need to contain the security condition, and the restriction is enforced inside the database engine.

Footnotes

1. Restricting Data Access Using the Virtual Private Database - Oracle overview of VPD policy functions and predicates. ↩

2. Using Oracle Virtual Private Database to Control Data Access - Oracle Database Security Guide explanation of dynamic SQL modification. ↩

1. What the Question Is Testing

The question describes four important components:

These clues identify fine-grained access control implemented through Oracle VPD. Oracle documentation explains that a protected object’s SQL statement is dynamically modified with a WHERE condition returned by a policy function.

Footnotes

1. Using Oracle Virtual Private Database to Control Data Access - Describes predicates as dynamically generated WHERE conditions. ↩

2. How VPD Works

A VPD policy normally consists of:

1. A protected relation, such as a table or view.
2. A policy function.
3. A policy definition that links the function to the relation.
4. A returned predicate.
5. Database enforcement during query processing.

The policy function can use session information, application context, user identity, roles, or other database information to determine the appropriate predicate.

A simplified conceptual model is:

$$\text{Effective Query} = \text{User Query} + \text{VPD Predicate}$$

For a query on orders, the policy function might return:

1customer_id = SYS_CONTEXT('APP_CTX', 'CUSTOMER_ID')

The database then ensures that a customer sees only the rows associated with that customer.

Footnotes

1. DBMS_RLS - Oracle reference for row-level security policy functions and predicates. ↩

3. A Conceptual Example

Assume an employees table contains:

A user submits:

1SELECT employee_id, employee_name, salary
2FROM employees;

The VPD policy function determines that the user belongs to department 10 and returns:

1department_id = 10

The effective query becomes conceptually:

1SELECT employee_id, employee_name, salary
2FROM employees
3WHERE department_id = 10;

The user sees Asha and Lin, but not Mateo. The application does not need to add a department filter to every query.

This is row-level security because authorization is applied at the row level rather than only at the table level.

Footnotes

1. Using Oracle Virtual Private Database to Control Data Access - Examples of row-level restrictions based on session attributes. ↩

4. The Oracle DBMS_RLS Interface

In Oracle Database, VPD policies are commonly administered through the DBMS_RLS package. The ADD_POLICY procedure associates a policy function with a database object and specifies the operations to which the policy applies.

Important conceptual parameters include:

The policy function commonly has access to the schema and object names and returns a character value containing a valid SQL predicate. Oracle’s documentation describes predicates as conditions dynamically added to statements accessing protected objects.

Footnotes

1. Restricting Access with Oracle Virtual Private Database - Oracle documentation describing policy-function configuration. ↩

2. DBMS_RLS - Oracle package reference for VPD policy administration. ↩

5. Dynamic Predicates and Session Context

A VPD function can generate different predicates for different users or sessions. For example:

• An administrator may receive 1 = 1, allowing all rows.
• A manager may receive department_id IN (10, 20).
• An employee may receive employee_id = 101.
• An unauthorized session may receive 1 = 0, returning no rows.

Oracle supports application contexts through SYS_CONTEXT. A policy function can read context attributes established for the current session and use them to produce an appropriate predicate.

A generalized predicate-selection model is:

$$P(u, c, r) = \begin{cases} 1 = 1, & \text{if the user is an administrator} \\ r.\text{department\_id} = c.\text{department\_id}, & \text{if the user is a manager} \\ r.\text{owner\_id} = u.\text{user\_id}, & \text{if the user is an individual customer} \\ 1 = 0, & \text{if access is denied} \end{cases}$$

Here:

• $u$ is the current user.
• $c$ is the session or application context.
• $r$ represents a candidate row.
• $P$ is the security predicate.

Footnotes

1. Using Oracle Virtual Private Database to Control Data Access - Explains application contexts and session-dependent predicates. ↩

6. VPD Compared with the Other Options

The alternatives describe identity or authentication technologies rather than predicate-based database row filtering.

OpenID and SAML operate primarily in the identity and federation layer. SAML allows an identity provider to communicate authentication information to a service provider, whereas VPD changes how the database evaluates access to protected relations.

A single-site system describes deployment scope, not a database policy mechanism.

Therefore, only VPD matches every part of the question.

Footnotes

1. How OpenID Connect Works - OpenID Foundation comparison of OpenID Connect and SAML. ↩

7. Strengths and Limitations

Strengths

• Centralized enforcement inside the database.
• Reduced dependence on application-layer filters.
• Dynamic behavior based on users, roles, and session context.
• Support for multi-tenant and departmental data isolation.
• Ability to apply policies to multiple SQL operation types.
• Transparent enforcement for direct and application-generated SQL.

Limitations and Risks

• Incorrect predicates can expose data or block legitimate access.
• Complex policy functions can affect parse and execution performance.
• Connection pooling requires careful session-context management.
• Privileged users and administrative bypass behavior must be reviewed.
• Policies must be tested with joins, views, synonyms, stored procedures, and bulk operations.
• Predicate logic should avoid unsafe string construction and unintended SQL behavior.

A useful security principle is:

$$\text{Effective Security} = \text{Correct Policy Logic} + \text{Correct Context Management} + \text{Comprehensive Testing}$$

Footnotes

1. Using Oracle Virtual Private Database to Control Data Access - Oracle description of transparent policy enforcement for protected objects. ↩