Search Results add_policy_context

Overview

SYS.DBMS_RLS is the Oracle-supplied administrative package that implements Fine-Grained Access Control (FGAC), commonly referred to as Virtual Private Database (VPD), within the Oracle database kernel. In Oracle E-Business Suite 12.1.1 and 12.2.2, the package resides in the SYS schema and holds VALID status, making it available to every EBS application schema through the standard EXECUTE grant to PUBLIC. Its business function is to let the database enforce row-level security transparently: a security policy function is bound programmatically to a table, view, or synonym, and the kernel automatically appends a predicate (WHERE clause) to every SQL statement issued against that object. EBS uses this mechanism to isolate data by operating unit, organization, ledger, or responsibility without requiring every form, report, and concurrent program to implement its own filtering logic. Because the package is owned by SYS and its interface is documented by Oracle, it is treated as a supported extension point for customizations rather than as an object subject to the normal EBS patching lifecycle.

Key Procedures and Functions

The documented interface comprises fifteen procedures and functions, grouped into policy management and policy-group management.

• ADD_POLICY — Attaches a new security policy to a database object, specifying the policy name, the schema and function that returns the predicate, the statement types to which the policy applies, and the policy behavior.
• ALTER_POLICY — Modifies the attributes of an existing policy without dropping and recreating it.
• DROP_POLICY — Removes a policy from an object.
• ENABLE_POLICY — Turns a policy on or off for a given object, or changes its enforcement mode.
• REFRESH_POLICY — Forces re-evaluation of a policy, typically after the underlying security function has changed.
• CREATE_POLICY_GROUP, DELETE_POLICY_GROUP — Create and remove named policy groups, which allow sets of policies to be managed and applied as a unit.
• ADD_GROUPED_POLICY, DROP_GROUPED_POLICY, ALTER_GROUPED_POLICY, ENABLE_GROUPED_POLICY, DISABLE_GROUPED_POLICY, REFRESH_GROUPED_POLICY — Add, remove, modify, enable, disable, and refresh policies within a policy group.
• ADD_POLICY_CONTEXT, DROP_POLICY_CONTEXT — Bind a named application context (for example, a CLIENTCONTEXT or CLIENTIDENTIFIER attribute) to a policy group so that drivers can later activate the correct group of policies.

Tables Accessed

DBMS_RLS does not read or write EBS application tables directly, and no APPS synonyms for application data are referenced by it. Internally, the package manipulates the data dictionary views and base tables that store FGAC definitions — principally the policy and policy-group metadata maintained by the RDBMS (for example, the policy definition views exposed as ALL_POLICIES, DBA_POLICIES, and the policy context and group catalogues). Those entries are then consumed by the SQL compiler at parse time to inject predicates into application SQL. Because all policy state lives in the data dictionary, changes made through DBMS_RLS take effect immediately for newly parsed statements and are visible across all EBS sessions and tiers.

Usage Notes

In Oracle EBS, DBMS_RLS is not normally invoked by end users or by standard concurrent programs. It is called from installation and configuration scripts, from database-level setup performed by the DBA, and by Oracle's own internal code; the package is referenced by DBMS_XDS, which exposes Data Security (VPD) capabilities, and by DBMS_GSM_CLOUDADMIN and the GSMADMIN_INTERNAL schema. Within EBS 12.1.1 and 12.2.2, row-level security for Multi-Org, ledger, and organization access is largely delivered through the Applications Context (CLIENTCONTEXT) and the FND security profile machinery, with DBMS_RLS providing the underlying policy registration and grouping facilities. Customizations that require additional row-level restrictions typically create a policy function returning a predicate string and register it with DBMS_RLS.ADD_POLICY (or ADD_GROUPED_POLICY when context-based activation is required), then bind the relevant context. Because the package is owned by SYS and is subject to strict privilege requirements, such customizations should be developed and tested carefully; changes to policies can affect every SQL statement against the protected object and can incur parse and runtime overhead. Only users granted EXECUTE on the package — directly or via PUBLIC — can administer policies, so exposure should be limited to authorized DBA accounts.