Search Results bism_permissions

Overview

BISM_PERMISSIONS is a repository table in the Oracle E-Business Suite Application Object Library (FND) product, owned by the APPLSYS schema. It stores privilege assignments that govern access between subject entities and object entities within the Oracle EBS security and permissions infrastructure. In the documented ETRM 12.2.2 physical schema, the table contains three columns: SUBJECT_ID, OBJECT_ID, and PRIVILEGE. The table is classified as VALID and is present in both the 12.1.1 and 12.2.2 releases of the E-Business Suite.

Under the heuristic Data Vault classification derived from its foreign-key structure, BISM_PERMISSIONS is modeled as standalone. This classification suggests that, from a strict referential-integrity standpoint, the table does not participate in a parent-child hub relationship through a dedicated surrogate key; instead, it functions as an associative or authorization mapping structure. Modelers designing a Data Vault representation might therefore treat it as a link-like association between subjects and objects, enriched by a PRIVILEGE descriptive attribute, rather than as a conventional hub or satellite.

Key Information Stored

The documented column set is compact, comprising three attributes that together define a permission grant:

• SUBJECT_ID — Identifies the subject to which a privilege is granted. A foreign key relationship is documented from BISM_PERMISSIONS.SUBJECT_ID to IGS_UC_COM_EBL_SUBJ, indicating that subject identifiers in this table resolve to records in the IGS subject table.
• OBJECT_ID — Identifies the object against which the privilege is asserted. This establishes the target of the permission relationship.
• PRIVILEGE — The privilege descriptor that defines the nature or level of access conferred upon the subject for the referenced object.

The metadata does not document a dedicated surrogate primary key column for this table, nor does it identify named unique indexes constituting business-key candidates. The combination of SUBJECT_ID and OBJECT_ID, together with PRIVILEGE, effectively serves as the logical identifying tuple for a permission grant. Because the table is documented as standalone with only one foreign key identified, SUBJECT_ID is the only column with a documented referential dependency.

Common Use Cases and Queries

BISM_PERMISSIONS is primarily queried to audit and report on privilege grants between subjects and objects. Typical scenarios include security reviews that enumerate all privileges held by a given subject, and access analyses that list all subjects holding a particular privilege over a given object. A representative query pattern follows:

SELECT p.SUBJECT_ID,
       p.OBJECT_ID,
       p.PRIVILEGE
FROM   APPLSYS.BISM_PERMISSIONS p
WHERE  p.SUBJECT_ID = :subject_id;

To resolve subjects to their descriptive records, join to the referenced subject table:

SELECT p.SUBJECT_ID,
       s.*,
       p.OBJECT_ID,
       p.PRIVILEGE
FROM   APPLSYS.BISM_PERMISSIONS p,
       IGS_UC_COM_EBL_SUBJ   s
WHERE  p.SUBJECT_ID = s.SUBJECT_ID;

Because the table is owned by APPLSYS and falls within the FND product, reporting queries should normally be run with the APPS schema or with appropriate synonyms and grants in place. Direct DML against APPLSYS objects is not recommended; permission maintenance should be performed through the supported application flows that populate this table.

Related Objects

The most significant documented relationship is the foreign key from BISM_PERMISSIONS.SUBJECT_ID to the subject table. Other objects share the BISM_ naming prefix and the FND/APPLSYS ownership context, and are commonly examined alongside this table when reviewing the permissions model:

• IGS_UC_COM_EBL_SUBJ — Referenced by BISM_PERMISSIONS.SUBJECT_ID; provides the subject-side identity for permission grants.
• FND_GRANTS / FND_OBJECTS — Adjacent FND security and object-registry tables frequently consulted in the same access-analysis workflows.
• FND_USER — Links application users to the security context in which subject privileges are evaluated.
• FND_RESPONSIBILITY — Defines the responsibility layer through which object-level privileges are enforced.
• FND_APPLICATION — Identifies the application owning the objects referenced by OBJECT_ID where applicable.

Any dependent views, APIs, or PL/SQL packages that read or write BISM_PERMISSIONS should be inventoried in the target instance, since the ETRM metadata documents only the single foreign key relationship above.