Search Results ext_auth_success




Overview
Explore in AI Chat

Overview

APPS.FND_SSO is a public PL/SQL package that implements the Oracle E-Business Suite integration layer for Single Sign-On (SSO) and externally managed authentication. Its package body, distributed as afssob.pls, encapsulates the calls required by third-party or external authentication providers so that they can validate user credentials, honor password policies, and resolve the identity under which an EBS session is established. Rather than exposing the underlying security engine directly, the package presents a small, stable programmatic contract that integration code and authentication adapters invoke.

The package belongs to the APPS schema and is classified as OTHER in the ETRM repository for release 12.2.2. Its design assumes that authentication is being delegated, so successful validation creates an Oracle EBS session and returns a well-defined status code to the caller. Failure modes are communicated through named exceptions and return constants such as EXT_AUTH_SUCCESS, EXT_AUTH_PASSWD_EXPIRED, and EXT_AUTH_FAILURE_EXCEPTION, all of which are referenced internally throughout the body.

Key Procedures and Functions

  • AUTHENTICATE_USER — The principal entry point for delegated login. It validates a supplied username and password combination against the EBS security engine; when validation succeeds it establishes a session and returns a success indicator, and when the credentials are valid but the password is expired it returns the corresponding expired-password status. It is declared with an autonomous transaction pragma so that its commit is independent of the caller's transaction. Invalid credentials raise EXT_AUTH_FAILURE_EXCEPTION, while any unexpected error is converted to EXT_AUTH_UNKNOWN_EXCEPTION.
  • GET_CONFIGURATION — Retrieves the SSO configuration settings used by the integration layer. It is the object most commonly searched for by administrators and developers who need to inspect or programmatically obtain the active SSO parameters without querying the configuration tables directly.
  • CHANGE_PASSWD — Allows a password to be changed through the external authentication path. It accepts the user, the current password, and the new password, delegates the update to the EBS web security engine, and raises EXT_CHANGE_PASSWORD_EXCEPTION if the change is not accepted. A null user raises EXT_NOT_SUPPORTED_EXCEPTION, and unhandled errors are re-raised as EXT_AUTH_UNKNOWN_EXCEPTION.
  • GET_AUTHENTICATION_NAME — Resolves and returns the authentication name associated with the user or session. It supports downstream processing that must know which authentication mechanism or identity was used.

Tables Accessed

The ETRM metadata does not list direct table references for this package. In practice, FND_SSO operates through the EBS security and SSO configuration application programming interfaces, so all persistence is performed by the underlying FND_WEB_SEC and SSO configuration routines that the package calls. The package body itself contains only the delegation logic and exception mapping; it holds no embedded SQL against application tables. Consequently, any configuration values surfaced by GET_CONFIGURATION are obtained through the same controlled security layer rather than by direct reads.

Usage Notes

FND_SSO is not a general-purpose utility. It is invoked when EBS is deployed with an external SSO provider or a custom authentication solution, typically from the authentication adapter or login flow that runs before an EBS session is fully established. Because AUTHENTICATE_USER commits inside an autonomous transaction and raises rather than returning errors for bad credentials, callers should wrap invocations in exception handlers and treat EXT_AUTH_FAILURE_EXCEPTION, EXT_AUTH_PASSWD_EXPIRED, and EXT_AUTH_UNKNOWN_EXCEPTION as distinct outcomes requiring different user responses.

The package is referenced by no other documented packages in the repository, which confirms its role as a top-level integration API consumed by external code rather than by internal EBS modules. Customizations should call the published procedures only, avoid modifying the package body in the APPS schema, and rely on GET_CONFIGURATION to read SSO settings rather than querying the underlying tables directly. Care should also be taken in concurrent or multithreaded authentication paths, since the autonomous transaction commit is deliberate and must not be assumed to roll back with the caller.