Results for “gms_security”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.GMS_SECURITY is a PL/SQL package body resident in the APPS schema that implements the security framework for Oracle Grants Management (GMS). Its principal responsibility is to evaluate and enforce whether a given user is permitted to query or update grants-related records, and to manage the session-level security context under which grants forms and concurrent programs operate. The package abstracts the underlying personnel and role-mapping logic so that individual grants forms do not need to embed authorization checks directly. It is classified as an OTHER API in the ETRM metadata for release 12.2.2, indicating it is an internal support package rather than a published integration interface. The object status is VALID, and it is referenced by eight other database objects, confirming its role as a shared dependency within the Grants module.

Key Procedures and Functions

The documented package exposes five program units:

• INITIALIZE — Establishes the security context for the current session. It prepares whatever cached state the remaining routines depend upon, and is normally the first call made before authorization checks are performed.
• ALLOW_QUERY — Determines whether the current user is authorized to view a given grants record or set of records. It acts as a read-access gate used by query-only paths.
• ALLOW_UPDATE — Determines whether the current user may modify the record under consideration. It mirrors ALLOW_QUERY but applies stricter criteria for write access.
• SET_VALUE — Assigns or registers a value within the package's security context, allowing callers to populate the state consulted by the ALLOW_* functions.
• CHECK_KEY_MEMBER — Validates membership of a key or identifier against the security context, typically used to confirm that a referenced person or grant key falls within the user's authorized scope.

These routines are intended to be called in sequence: context initialization, key validation, then the appropriate allow/disallow test. No parameter lists are documented in the ETRM extract and are therefore not reproduced here.

Tables Accessed

The package body references two tables through APPS synonyms:

• GMS_PERSONNEL — The primary source of security-relevant personnel data. Membership and role information held in this table underpins the decisions returned by ALLOW_QUERY, ALLOW_UPDATE, and CHECK_KEY_MEMBER.
• DUAL — Used for single-row evaluations, constant returns, and lightweight existence checks that do not require a physical table.

In addition to these tables, the body depends on the standalone package GMS_SECURITY_EXTN, the PA_UTILS utility package, and its own specification GMS_SECURITY. The GMS_SECURITY_EXTN dependency indicates that the core logic delegates to an extension point, allowing installations to customize security behavior without modifying the seeded package. The absence of any referencing database object in the dependency listing confirms that GMS_SECURITY is a top-level consumer of these resources rather than a subordinate module.

Usage Notes

GMS_SECURITY is invoked indirectly rather than by end users. Grants forms call it during record navigation, query execution, and before committing changes, so that unauthorized rows are filtered and unauthorized updates are blocked before reaching the database. Concurrent programs and reports in the Grants module may call it to scope extracted data to the requesting user's authorized personnel set. Custom code that reads or writes grants tables should call INITIALIZE followed by the relevant ALLOW_* function to remain consistent with the standard security model, and should rely on the GMS_SECURITY_EXTN hook for site-specific variations instead of altering the seeded package body. Because the package is referenced by eight other objects, changes to it carry broad impact across Oracle Grants Management and should be regression-tested accordingly.