TECHNOLOGY: Security

Creating Custom Authentication

By Raj Mattamal

Build single sign-on/sign-off for a suite of applications in Oracle Application Express.

Although Oracle Application Express has excellent out-of-the-box options for authenticating users, it is sometimes necessary to write custom authentication schemes to meet specific requirements. Such was the case for one client I worked with, a large government contractor with several Oracle Database instances already deployed and some fairly restrictive requirements, specifically

Users must be able to run Oracle Application Express applications from any of the Oracle instances while having to authenticate only once

Users must be able to sign out of any application and have that sign-off apply to all other applications

This article steps through an example implementation, based on my experience with that client. It provides single-sign-on and single-sign-off functionality for a suite of Oracle Application Express applications, by assembling two custom authentication schemes that incorporate custom code while leveraging native Oracle Application Express functionality whenever possible.

Overview of the Implementation

In the client solution, each Oracle Application Express instance runs several different applications. One of the Oracle Application Express applications has been designated as the “login application.” All the other Oracle Application Express applications are “auxiliary applications” in the suite.

Unauthenticated requests to access applications are redirected to the login application, which presents users with an authentication challenge. At the client site, the login application is integrated with Microsoft Active Directory for username and password management, but any technique for verifying user identity can be used with this method, as long as it ultimately resolves to a true or a false value. With successful authentication, users receive a “suite cookie” that facilitates transparent authentication to all other suite applications.

Signing off from any application in the suite initiates a recursive sign-off process across all applications. The login application’s schema owns a table containing details about all applications in the suite, and this table is used by a procedure that signs users off from each application and cancels the suite cookie.

Create Single Sign-on, Using Authentication Schemes

The client’s implementation uses two custom authentication schemes: the suite login authentication scheme and the auxiliary authentication scheme. The main components needed to enable single sign-on across the suite of applications using these schemes are

A mechanism that sets a suite cookie upon successful credential verification

A means of redirecting users without valid sessions to the login application

A way to check for the suite cookie upon subsequent page views

Getting started. To get started on creating and deploying these customer authentication schemes in your own suite of applications, first download the zip file and extract the contents. The download contains four SQL files—ns_auth_util.sql, ns_auth_aux.sql, login_logout_procs .sql, and table_ddl.sql—that need to be uploaded to Oracle Application Express.

2. Click Upload , and on the Upload Script page, for File , browse to a file from the download such as ns_auth_util.sql, and click Upload

3. Repeat the previous step for the remaining files from the download

Setting up the suite login authentication scheme. Begin constructing the custom authentication solution by creating the login authentication scheme. In Oracle Application Express, go to the application designated as the login application and create a new authentication scheme from scratch.

Setting the authentication function. One of the entry points for integrating custom code into an Oracle Application Express authentication scheme is the authentication function. Oracle Application Express can run custom authentication function code to validate a username/password combination.

Listing 1 contains the code from the ns_auth_util.sql file you uploaded earlier; that code includes the ns_auth_util package and CHECK_CREDENTIALS—a custom authentication function. To plug the CHECK_CREDENTIALS function call into the suite login authentication scheme, add it as the authentication function.

Upon successful verification, the CHECK_CREDENTIALS function also calls the SET_SSO_COOKIE procedure, which sets the suite cookie that enables subsequent, transparent authentications to other applications in the suite. Note that for demonstration purposes, the CHECK_CREDENTIALS function checks the values of the EMP table, which installs with the sample application in every Oracle Application Express instance.

Setting up the auxiliary authentication scheme. Now set up the auxiliary authentication scheme on any Oracle Application Express instance that contains applications considered part of the suite. As with the suite login authentication scheme, create a new scheme from scratch.

1. For an auxiliary application in the suite, on the Shared Components page, under Security, click Authentication Schemes .

2. On the Authentication Schemes page, click Create .

3. On the Create Authentication Scheme page, for Create Scheme , select From scratch and click Next .

Setting up LOGIN_PAGE to handle unauthenticated users. This Oracle Application Express custom authentication framework checks for a valid suite cookie whenever users navigate to any application within the suite. Requests from users without a cookie are considered unauthenticated. In this example, both the suite login authentication scheme and the auxiliary authentication scheme integrate a custom procedure, LOGIN_PAGE, to properly handle unauthenticated users:

This procedure uses the owa_util.redirect_url API to send users to the login page of the login application. This is done rather than hard-coding the available Session Not Valid URL attribute, to allow for easier maintenance. Because the procedure is called via a URL, the mod_plsql DAD user needs to be granted access to it:

grant execute on login_page to
apex_public_user;

The call to the LOGIN_PAGE procedure is specified in the suite login authentication scheme as well as in all auxiliary authentication schemes in the form of a relative URL.

To add this LOGIN_PAGE procedure call to the suite login authentication scheme

To add the LOGIN_PAGE procedure call to all auxiliary authentication schemes, repeat the preceding steps for each of those schemes. Using a page sentry function to validate the session. The other function critical to custom authentication schemes is the confirmation of a valid session with each requested page view. In Oracle Application Express, the page sentry function performs this duty. At a minimum, the custom page sentry function for this implementation’s authentication schemes must perform the following tasks in the order specified:

1. Confirm that the current user’s Web browser has a valid suite cookie.

2. Confirm that the current user’s Web browser has a valid Oracle Application Express session cookie for the currently requested application.

3. Confirm that the username from the suite cookie matches the Oracle Application Express session cookie.

4. Instantiate a new Oracle Application Express session or rejoin the existing session if the previous three conditions are met.

The ns_auth_aux.sql script, included with the download for this article, contains the code for the page sentry function (SENTRY). The page sentry function uses several of the Oracle Application Express authentication APIs from the APEX_CUSTOM_AUTH package that facilitate working with sessions, specifically

IS_SESSION_VALID , which checks to see that the invoking Oracle Application Express application has a valid session

GET_USERNAME , which retrieves the username associated with the session if the Oracle Application Express session is valid

GET_SESSION_ID_FROM_COOKIE , which retrieves the Oracle Application Express session ID from the Oracle Application Express session cookie stored by the user’s Web browser, if available

LOGOUT , which expires the Oracle Application Express session and redirects the user’s browser to a specified location

Every application in the suite must perform the suite and session cookie checks with each page view, so include the call to the SENTRY function for the page sentry function of the suite login authentication scheme and all auxiliary authentication schemes.

To add this SENTRY function call to the suite login authentication scheme

To add the SENTRY function call to all auxiliary authentication schemes, repeat the preceding steps for each of those schemes.

With the SENTRY function added to all of the suite’s authentication schemes, any application in the same domain as the suite cookie will respect the single-sign-on functionality.

Single-Sign-off Implementation

Signing users off from applications in the suite is somewhat more challenging than signing on, because it is not simply a matter of expiring the suite cookie set during authentication. For a proper sign-off, the session information for each application in the suite must also be expired.

Three additional constructs—a table, a logout procedure, and a branching logout page—work together to provide this single-sign-off mechanism.

Table of suite applications for logout. With authenticated applications potentially being distributed across multiple database instances, the implementation must be able to visit each application in the suite to ensure deauthentication before returning users to the login page. A table, NS_SUITE_APPS, contains the necessary information about every application in the suite.

The NS_SUITE_APPS table is stored in the schema of the login application, but it must be accessible to the schemas of every application. For any schemas on the same instance as the login application, grant the schema access to the table. For any schemas on the other instances, set up a database link and a synonym, NS_SUITE_APPS.

Listing 2 contains the data definition language for the NS_SUITE_APPS table. The following columns from that table are used by the single-sign-out procedure:

APP_ID , the identification number of the application from which the user is to be deauthenticated

LOGOUT_PAGE_ID , the page number of the logout page associated with the application

HOST_PORT , the host and port of the Web server providing access to the application

INSTANCE , the logical name of the application’s database instance

APP_ALIAS , the alias of the application as defined on the application-level attributes page

Unique constraints defined on the APP_ALIAS and APP_ID columns simplify the flow of the example code, but if you remove these constraints, be sure to modify the main cursor of the logout procedure accordingly.

Log out from all suite applications. The logout procedure (included in the ns_auth_aux package) recursively expires all applications’ session data and ultimately redirects users to the public login page. The procedure accomplishes this by stepping through the applications in the NS_SUITE_APPS table in a known order. After all suite applications have been deauthenticated, the procedure takes users to the public login page.

Note that the packaged logout procedure is actually called via the following wrapper procedure:

The logout procedure call is isolated in this fashion to minimize the scope of the privileges granted to the mod_plsql DAD user. Because the procedure is called via a URL, the mod_plsql DAD user must have execution privileges on the procedure. Wrapping the packaged logout procedure in effect limits the scope of this grant.

The logout procedure is called from both the logout navigation link and a logout page. By default, Oracle Application Express defines the URL target of this link to be &LOGOUT_URL. (This built-in Oracle Application Express substitution variable references the logout URL attribute specified in the application’s authentication scheme.)

Now update the target of the logout URL link to use the NS_LOGOUT (ns_auth_aux.logout) procedure in the suite login authentication scheme and all auxiliary authentication schemes.

To update the logout URL for all the auxiliary authentication schemes, repeat the preceding steps for each of those schemes.

Note that the locally stored logout procedure is called without passing through an application alias. Invoking NS_LOGOUT this way starts the recursive logout process driven by the cursor query executed against the NS_SUITE_APPS table:

This query returns all applications from the table with an ACTIVE status, and it does so in a known order. Because a P_APP_ID value is not specified in the call, the routine starts at the top of the list.

Logout page for branching logic for the logout process. In addition to the logout navigation link, a logout page that provides the necessary branching logic for the logout process must be available in each application in the suite. In this example, the logout page is identified by the LOGOUT_PAGE_ID in the NS_SUITE_APPS table. The logout page contains one branch firing with a branch point value of Before Header.

2. On the details page, under Page Processing and Branches, click the branch for the logout procedure

3. On the Edit Branch page, in the Point section, for Branch Point , select On Load: Before Header

4. On the Edit Branch page, in the Action section, for Target type , select URL , and in the URL Target text box, enter

#OWNER#.ns_logout?p_app_alias=&APP_ALIAS.

5. Click Apply Changes

The target of the branch firing in the logout page is a call back to the logout procedure, but using the application alias. By passing through the application alias, the procedure keeps track of where it is in the list of applications. For every application in the list, the logout procedure logs the user out from the current application and redirects the user’s browser to the next application for deauthentication.

When the logout procedure reaches the last application in the list, the procedure logs the user out from the application, expires the suite cookie, and redirects the user to the public login page. With this last step, the single-sign-out process is complete.

Conclusion

When my team implemented this authentication mechanism at the client site, the rollout was a success. Being a large government contractor, the client put the solution through a rather rigorous security review, which it passed without issue. A major contributing factor to that success was the leveraging of the existing authentication infrastructure that Oracle Application Express provides developers. Because our implementation augmented the authentication functionality already performed by Oracle Application Express, the security review was brief as well.

Finally, it is important to reiterate that you should almost always try to take this approach when adding custom code to any Oracle Application Express application: leverage existing infrastructure whenever possible, and add customizations as necessary. As demonstrated by this article, following this approach makes even more-advanced tasks, such as developing custom authentication mechanisms, straightforward and manageable.

Raj Mattamal (rmattamal@nianticsystems.com) is a copresident at Niantic Systems, LLC, a New Jersey-based consultancy specializing in Oracle Application Express solutions and training.