Search Results set_protection_realm




Overview
Explore in AI Chat

Overview

OWAPUB.OWA_SEC is the Oracle PL/SQL Agent security package, a component of the Oracle Web Agent (OWA) toolkit that ships with the Oracle database and is exposed within Oracle E-Business Suite 12.1.1 and 12.2.2 for backward compatibility with HTML-based and web-enabled PL/SQL applications. Its business function is to control authorization and to expose authentication context to PL/SQL code that generates dynamic web content. The package defines the authorization schemes available to the PL/SQL Agent and provides a small set of accessors that report who the web client is, from which host and IP address the request originated, and what credentials were presented.

The package body declares four integer constants that represent the supported authorization modes: NO_CHECK (1, no authorization check), GLOBAL (2, a single global check), PER_PACKAGE (3, an authorization procedure defined in each package), and CUSTOM (4, a user-defined authorization procedure such as owa_custom.authorize). These constants are the vocabulary through which a calling application tells the agent how a request should be validated before the target procedure is permitted to execute. OWAPUB.OWA_SEC is classified under the OTHER API classification and is owned by SYS, indicating it is a database-supplied package rather than an EBS application-owned object.

Key Procedures and Functions

The documented interface comprises six callable units, all declared in the package specification:

  • SET_AUTHORIZATION — A procedure that specifies the PL/SQL Agent's authorization scheme. It accepts the scheme value, conventionally one of the constants NO_CHECK, GLOBAL, PER_PACKAGE, or CUSTOM, and governs how subsequent requests are validated.
  • GET_USER_ID — A function returning the user identifier supplied by the web client during authentication; used by application code to identify the authenticated principal.
  • GET_PASSWORD — A function returning the password presented by the web client, allowing application logic to perform its own credential validation when a custom scheme is in force.
  • GET_CLIENT_IP — A function returning the originating client IP address, typed as owa_util.ip_address; useful for auditing, logging, and network-based restrictions.
  • GET_CLIENT_HOSTNAME — A function returning the hostname of the requesting web client, supporting host-based access decisions and diagnostics.
  • SET_PROTECTION_REALM — A procedure that specifies the dynamic page's protection realm, the realm string presented to the browser in the authentication challenge.

Tables Accessed

The documented ETRM metadata records no tables referenced through APPS synonyms for this package. This is consistent with its role as a low-level agent interface: OWAPUB.OWA_SEC operates on the state of the PL/SQL Agent and on request-supplied authentication data rather than on EBS application tables. Any persistence of authorization outcomes or audit trails is the responsibility of the calling application, not of this package.

Usage Notes

OWAPUB.OWA_SEC is typically invoked from web-enabled PL/SQL procedures or packages that are dispatched by the PL/SQL Agent. A common pattern is to call SET_AUTHORIZATION and SET_PROTECTION_REALM early in request processing, then use GET_USER_ID, GET_PASSWORD, GET_CLIENT_IP, and GET_CLIENT_HOSTNAME to implement or log custom authorization decisions. The package is referenced by two other database packages per the documented metadata, confirming that it is a dependency for higher-level agent utilities rather than a directly exposed application interface.

In an EBS 12.1.1 or 12.2.2 environment, this object is a legacy component associated with the older HTML/PLSQL web stack and is not part of the standard Oracle Forms-based EBS navigation. Customization or reliance on it should be limited to custom web-enabled PL/SQL code, and any custom authorization procedure invoked through the CUSTOM scheme must exist and be executable by the agent. Because the package is owned by SYS and shipped with the database, it should never be modified; behavioral changes must be implemented in application-level wrapper code.