Search Results rekey_concurrent

Overview

FND_VAULT is a low-level Oracle E-Business Suite security utility that provides a centralized, PL/SQL-only key/value store for sensitive session data such as passwords, tokens, and credentials. Rather than persisting secrets in a conventional table accessible through ordinary SQL, FND_VAULT stores values through PL/SQL entry points only, so that a value written by the PUTS routine cannot be retrieved by a plain SELECT or modified by an UPDATE against the underlying store. The package is defined with AUTHID CURRENT_USER, meaning that name resolution and privilege checks for referenced objects execute under the privileges of the calling user, and it is owned by the APPS schema in both 12.1.1 and 12.2.2. Because it is a foundational service, FND_VAULT is referenced by 21 other packages in the application, and it is the mechanism behind the storage of sensitive values used by concurrent managers, workflow, and other server-side components.

Key Procedures and Functions

The package exposes a small, deliberately simple interface organized around a service name and a variable name that together form the lookup key.

• PUT / PUTS — Store a VARCHAR2 value under a service/variable combination. If the combination already exists, the current value is replaced. The PUTS variant stores the value in a manner that is not retrievable through a select or update statement, restricting access to PL/SQL code.
• PUTR — Stores a RAW value under a service/variable combination, with a secure flag controlling the protected storage behavior.
• GET / GETR — Retrieve a previously stored value for a service/variable combination; GET returns the VARCHAR2 representation and GETR returns the RAW representation.
• DEL — Removes stored values associated with a given service and variable.
• REKEY — Re-encrypts, or re-keys, the stored vault contents when encryption keys change.
• REKEY_CONCURRENT — The concurrent-program wrapper for the re-key operation, allowing vault re-keying to run as a scheduled background job rather than an interactive session.
• TST — A test/validation entry point used to verify package function and round-trip storage.
• ALLOWED — Reports whether a given service or variable is permitted for the calling context, enforcing the access policy for the vault.

Tables Accessed

FND_VAULT persists its data primarily through the FND_USER_PREFERENCES table, using it as the physical backing store for service/variable/value records rather than maintaining a dedicated vault table. It relies on DBMS_LOCK for serialization during write and re-key operations, DBMS_SESSION to manage session-scoped state and identity, and UTL_RAW to convert and manipulate RAW values for the GETR and PUTR interfaces. The use of these standard packages ensures the vault remains portable across database releases supported by EBS 12.1.1 and 12.2.2.

Usage Notes

FND_VAULT is not intended for direct end-user invocation. It is called by other PL/SQL packages, by forms when a credential must be cached for a session, and by concurrent programs when secrets must be stored or rotated. The presence of REKEY and REKEY_CONCURRENT reflects the operational model: administrators schedule the re-key concurrent program to migrate vault contents whenever the underlying key material changes, minimizing exposure of stale secrets. The user search term "rekey_concurrent" corresponds directly to the REKEY_CONCURRENT procedure, the documented concurrent-program entry point for this operation. Custom code that needs to persist a secret should call PUTS rather than PUT, and should read values back exclusively through GET or GETR so that the protection semantics of the vault are preserved. Because privileges are evaluated under AUTHID CURRENT_USER, grants on FND_VAULT and the referenced tables must be verified after cloning or schema changes.