Skip Headers
Oracle® Application Express Application Builder User's Guide
Release 4.0

Part Number E15517-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF · Mobipocket

13 Managing Application Security

This section describes how to implement security best practices for Oracle Application Express. Administrators are primarily responsible for ensuring the security of the Oracle Application Express installation, while developers are responsible for building secure applications.

Topics:

See Also:

"Application Builder Concepts" and "Using Application Builder"

Understanding Administrator Security Best Practices

This section describes security best practices for Oracle Application Express administrators.

Topics:

Security Considerations When Using the Embedded PL/SQL Gateway

The embedded PL/SQL gateway runs in the database as part of the XML DB HTTP Protocol Listener. The XML DB HTTP Protocol Listener and embedded PL/SQL gateway provides the equivalent core features of Oracle HTTP Server and mod_plsql. Because the HTTP Listener runs in the same database where Oracle Application Express is installed, it is not possible to separate the HTTP listener from the database. For this reason, it is not recommended to use the embedded PL/SQL gateway for applications that run on the Internet. Additionally, the embedded PL/SQL gateway does not provide the same flexibility of configuration and detailed logging as Oracle HTTP Server with mod_plsql.

About Configuring Oracle HTTP Server with mod_plsql for Oracle Application Express

Oracle HTTP Server uses the mod_plsql plug-in to communicate with the Oracle Application Express engine within the Oracle database. mod_plsql functions act as a communication broker between the Web server and the Oracle Application Express engine in the Oracle database.

Each mod_plsql request is associated with a set of configuration values used to access the database called a Database Access Descriptor (DAD). mod_plsql provides a DAD parameter called PlsqlRequestValidationFunction which enables you to allow or disallow further processing of a requested procedure. You can utilize this parameter to implement tighter security for your PL/SQL application by blocking package and procedure calls which should not be allowed to run from the DAD. Oracle recommends a DAD configuration for Oracle Application Express which utilizes the PlsqlRequestValidationFunction directive with a value of wwv_flow_epg_include_modules.authorize.

The purpose of the PlsqlRequestValidationFunction parameter is to control which procedures can be invoked through mod_plsql. By default, the only procedures permitted are the public entry points of Oracle Application Express. This can be extended using the validation functions shipped with Oracle Application Express. To learn more, see "Restricting Access to Oracle Application Express" in Oracle Application Express Administration Guide.

Utilizing Secure Sockets Layer (SSL)

Secure Sockets Layer (SSL) is a protocol for managing the security of data transmitted on the Internet. For Web applications, SSL is implemented by using the HTTPS protocol. Oracle recommends that you run Oracle Application Express applications using SSL (HTTPS protocol) to prevent any sensitive data from being sent over an unencrypted (cleartext) communication channel.

You can configure both your Oracle Application Express instance and all related applications to require HTTPS by setting the Require HTTPS attribute to Yes on the on the Manage Service page in Oracle Application Express Administration Services.

Setting the Require HTTPS attribute to Yes and logging out prevents anyone from logging in to Oracle Application Express Administration Services and from logging into an Oracle Application Express workspace as a developer or administrator unless the protocol in use is HTTPS.

See Also:

"Requiring HTTPS" in Oracle Application Express Administration Guide

Integrating with Oracle BI Publisher

Oracle recommends that you employ Secure Sockets Layer (SSL) when integrating Oracle Application Express with Oracle BI Publisher. Once SSL (HTTPS protocol) is configured for your Oracle BI Publisher server, you must create a wallet and specify the HTTPS protocol for the Report Server in the internal administration Environment Settings.

See Also:

"Configuring Wallet Information" and "Configuring Report Printing" in Oracle Application Express Administration Guide

About Setting Password Complexity Rules

Workspace administrators and developers can create user accounts for the purpose of logging in to the Oracle Application Express development environment and for end-user authentication to applications developed within their workspaces. The Oracle Application Express administrator can create password complexity rules, or a policy, for the passwords of these accounts. These rules apply to all accounts in the installation, across all workspaces.

The following are example password complexity policies:

All passwords must:

  • Contain at least one upper-case character

  • Contain at least one numeric digit

  • Must be at least six characters long

Note that many other variations are possible. Oracle recommends administrators establish a password complexity policy for each Oracle Application Express instance. To learn more, see "Enabling Login Controls for All Workspaces," "About Password Policies," and "Enabling Login Controls for a Workspace" in Oracle Application Express Administration Guide.

Restricting Password Reuse

Site administrators can restrict password reuse for all administrator, developer, and end-user accounts based on a history of passwords previously used for the accounts.

To restrict password reuse:

  1. Start SQL*Plus and connect to the database where Oracle Application Express is installed having the apex_administrator_role role or as SYS specifying the SYSDBA role. For example:

    • On Windows:

      SYSTEM_DRIVE:\ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
    • On UNIX and Linux:

      $ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
  2. Execute the following statement:

    ALTER SESSION SET CURRENT_SCHEMA = APEX_040000;
    
    
  3. Execute the following statement:

    BEGIN
    APEX_INSTANCE_ADMIN.SET_PARAMETER('PASSWORD_HISTORY_DAYS',365);
    COMMIT;
    END;
    /
    

    This will restrict new or updated passwords to those that have not been used for the account for the previous 365 days. Recording of previously used passwords (actually, hashed representations of passwords) begins upon installation of Oracle Application Express 4.0.

  4. To disable this feature, run the block above, providing 0 for the parameter value. For example:

    BEGIN
    APEX_INSTANCE_ADMIN.SET_PARAMETER('PASSWORD_HISTORY_DAYS',0);
    COMMIT;
    END;
    /
    

Tip:

Developers can also use the APEX_UTIL.STRONG_PASSWORD_CHECK procedure and the APEX_UTIL.STRONG_PASSWORD_VALIDATION function described in Oracle Application Express API Reference.

Advantages of the Oracle Application Express Runtime Environment

An Oracle Application Express runtime environment enables you to run production applications, but it does not provide a Web interface for administration or direct development of these applications

Oracle recommends that you run any sensitive production Oracle Application Express applications with a runtime installation of Oracle Application Express. A runtime installation does not expose the Web-based application development environment, thus preventing the use of Application Builder, SQL Workshop, and related utilities on a production installation. Additionally, a runtime environment only includes the Oracle Application Express database objects and privileges necessary to run applications, making it a more hardened environment.

See Also:

"Managing a Runtime Environment" in Oracle Application Express Administration Guide

Understanding Session Timeout

By configuring Session Timeout attributes, you can reduce your application's exposure. Users often leave their computers unattended for extended periods and do not close applications before departing. Therefore, an unauthorized person can easily assume the user's identity within the application. By setting the session and idle timeout, users are automatically logged out of their application after the specified timeout.

Session Timeout attributes include:

  • Maximum Session Length in Seconds

  • Session Timeout URL

  • Maximum Session Idle Time in Seconds

  • Idle Timeout URL

To learn more about configuring these attributes at an application-level, see "Session Timeout". To learn more about configuring these attributes for an entire Oracle Application Express instance, see "Configuring Session Timeout" in Oracle Application Express Administration Guide.

Enabling Network Services in Oracle Database 11g

By default, the ability to interact with network services is disabled in Oracle Database 11g. Therefore, if you are running Oracle Application Express with Oracle Database 11g, you must use the new DBMS_NETWORK_ACL_ADMIN package to grant connect privileges to any host for the APEX_040000 database user. Failing to grant these privileges results in issues with:

  • Sending outbound mail in Oracle Application Express.

    Users can call methods from the APEX_MAIL package, but issues arise when sending outbound email.

  • Using Web services in Oracle Application Express.

  • PDF/report printing.

  • Searching for content in online Help (that is, using the Find link).

Topics:

Tip:

To run the examples described in this section, the compatible initialization parameter of the database must be set to at least 11.1.0.0.0. By default an 11g database will have the parameter set properly, but a database upgraded to 11g from a prior version may not. See "Creating and Configuring an Oracle Database" in Oracle Database Administrator's Guide for information about changing database initialization parameters.

Granting Connect Privileges to a Host

The following example demonstrates how to grant connect privileges to a host for the APEX_040000 database user.

DECLARE
  ACL_PATH  VARCHAR2(4000);
  ACL_ID    RAW(16);
BEGIN
  -- Look for the ACL currently assigned to '*' and give APEX_040000
  -- the "connect" privilege if APEX_040000 does not have the privilege yet.

  SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
   WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;

  -- Before checking the privilege, make sure that the ACL is valid
  -- (for example, does not contain stale references to dropped users).
  -- If it does, the following exception will be raised:
  --
  -- ORA-44416: Invalid ACL: Unresolved principal 'APEX_040000'
  -- ORA-06512: at "XDB.DBMS_XDBZ", line ...
  --
  SELECT SYS_OP_R2O(extractValue(P.RES, '/Resource/XMLRef')) INTO ACL_ID
    FROM XDB.XDB$ACL A, PATH_VIEW P
   WHERE extractValue(P.RES, '/Resource/XMLRef') = REF(A) AND
         EQUALS_PATH(P.RES, ACL_PATH) = 1;

  DBMS_XDBZ.ValidateACL(ACL_ID);
   IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_040000', 
     'connect') IS NULL THEN 
      DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH, 
     'APEX_040000', TRUE, 'connect'); 
  END IF;

EXCEPTION
  -- When no ACL has been assigned to '*'.
  WHEN NO_DATA_FOUND THEN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('power_users.xml',
    'ACL that lets power users to connect to everywhere',
    'APEX_040000', TRUE, 'connect');
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('power_users.xml','*');
END;
/
COMMIT;

Granting Connect Privileges to a Local Host

The following example is a less privileged demonstration of how to access resources on a local host. This example would enable indexing of Oracle Application Express Online Help and could possibly enable email and PDF printing if those servers were also on the local host.

DECLARE
  ACL_PATH  VARCHAR2(4000);
  ACL_ID    RAW(16);
BEGIN
  -- Look for the ACL currently assigned to 'localhost' and give APEX_040000
  -- the "connect" privilege if APEX_040000 does not have the privilege yet.
  SELECT ACL INTO ACL_PATH FROM DBA_NETWORK_ACLS
   WHERE HOST = 'localhost' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;

  -- Before checking the privilege, make sure that the ACL is valid
  -- (for example, does not contain stale references to dropped users).
  -- If it does, the following exception will be raised:
  --
  -- ORA-44416: Invalid ACL: Unresolved principal 'APEX_040000'
  -- ORA-06512: at "XDB.DBMS_XDBZ", line ...
  --

  SELECT SYS_OP_R2O(extractValue(P.RES, '/Resource/XMLRef')) INTO ACL_ID
    FROM XDB.XDB$ACL A, PATH_VIEW P
   WHERE extractValue(P.RES, '/Resource/XMLRef') = REF(A) AND
         EQUALS_PATH(P.RES, ACL_PATH) = 1;

  DBMS_XDBZ.ValidateACL(ACL_ID);
   IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(ACL_PATH, 'APEX_040000', 
     'connect') IS NULL THEN 
      DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(ACL_PATH, 
     'APEX_040000', TRUE, 'connect'); 
  END IF;

EXCEPTION
  -- When no ACL has been assigned to 'localhost'.
  WHEN NO_DATA_FOUND THEN
  DBMS_NETWORK_ACL_ADMIN.CREATE_ACL('local-access-users.xml',
    'ACL that lets power users to connect to everywhere',
    'APEX_040000', TRUE, 'connect');
  DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL('local-access-users.xml','localhost');
END;
/
COMMIT;

Troubleshooting an Invalid ACL Error

If you receive an ORA-44416: Invalid ACL error after running the previous script, use the following query to identify the invalid ACL:

REM Show the dangling references to dropped users in the ACL that is assigned
REM to '*'.

SELECT ACL, PRINCIPAL
  FROM DBA_NETWORK_ACLS NACL, XDS_ACE ACE
 WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL AND
       NACL.ACLID = ACE.ACLID AND
       NOT EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL);

Next, run the following code to fix the ACL:

DECLARE
  ACL_ID   RAW(16);
  CNT      NUMBER;
BEGIN
  -- Look for the object ID of the ACL currently assigned to '*'
  SELECT ACLID INTO ACL_ID FROM DBA_NETWORK_ACLS
   WHERE HOST = '*' AND LOWER_PORT IS NULL AND UPPER_PORT IS NULL;

  -- If just some users referenced in the ACL are invalid, remove just those
  -- users in the ACL. Otherwise, drop the ACL completely.
  SELECT COUNT(PRINCIPAL) INTO CNT FROM XDS_ACE
   WHERE ACLID = ACL_ID AND
         EXISTS (SELECT NULL FROM ALL_USERS WHERE USERNAME = PRINCIPAL);

  IF (CNT > 0) THEN

    FOR R IN (SELECT PRINCIPAL FROM XDS_ACE
               WHERE ACLID = ACL_ID AND
                     NOT EXISTS (SELECT NULL FROM ALL_USERS
                                  WHERE USERNAME = PRINCIPAL)) LOOP
      UPDATE XDB.XDB$ACL
         SET OBJECT_VALUE =
               DELETEXML(OBJECT_VALUE,
                         '/ACL/ACE[PRINCIPAL="'||R.PRINCIPAL||'"]')
       WHERE OBJECT_ID = ACL_ID;
    END LOOP;

  ELSE
    DELETE FROM XDB.XDB$ACL WHERE OBJECT_ID = ACL_ID;
  END IF;

END;
/

REM commit the changes.

COMMIT;

Once the ACL has been fixed, you must run the first script in this section to apply the ACL to the APEX_040000 user. See "Granting Connect Privileges to a Host".

Enabling Indexing of Online Help in Oracle Database 11gR2 and Higher

The ability to search Oracle Application Express online Help is accomplished through Oracle Text and a URL datastore. There is a change in the default behavior and permissions to use an Oracle Text URL datastore in database 11gR2 and higher.

If users attempt to search Oracle Application Express online Help in Oracle database 11gR2 and encounter the following error, then the permission to use an Oracle Text URL datastore has not been granted to database user APEX_040000.

ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine 
ORA-20000: Oracle Text error: 
DRG-10758: index owner does not have the privilege to use file or URL datastore

To enable the indexing of online Help in Oracle Application Express, the permission to use an Oracle Text URL datastore must be granted to the APEX_040000 database user. This is accomplished by assigning this specific privilege to a database role and then granting this role to the APEX_040000 database user.

To determine if the ability to use an Oracle Text URL datastore is already granted to a database role:

  1. Start SQL*Plus and connect to the database where Oracle Application Express is installed as SYS specifying the SYSDBA role. For example:

    • On Windows:

      SYSTEM_DRIVE:\ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
    • On UNIX and Linux:

      $ sqlplus /nolog
      SQL> CONNECT SYS as SYSDBA
      Enter password: SYS_password
      
  2. Run the following command:

    SELECT par_value FROM ctxsys.ctx_parameters WHERE par_name = 'FILE_ACCESS_ROLE';
    

    This returns either NULL or the database role which is granted the ability to use an Oracle Text URL datastore.

  3. If no value is returned by step 2, then create a new database role as shown in the following example:

    CREATE ROLE APEX_URL_DATASTORE_ROLE;
    
  4. Grant this role to the database user APEX_040000 with the following statement:

    GRANT APEX_URL_DATASTORE_ROLE to APEX_040000;
    

    If step 2 returned a value, use this database role name instead of the example APEX_URL_DATASTORE_ROLE.

  5. Lastly, if step 2 did not return a value, then use the Oracle Text API to grant permission to the newly created database role with the following statement:

    EXEC ctxsys.ctx_adm.set_parameter('file_access_role', 'APEX_URL_DATASTORE_ROLE');
    

Understanding Developer Security Best Practices

This section describes security best practices for Oracle Application Express developers.

Topics:

Understanding Items of Type Password

Password items do not emit the text entered to the Web browser screen. When creating password items, Oracle recommends using password attributes that do not save session state. This prevents the password from being saved in the database in the session state tables.

Configurable password item type attributes include:

  • Value Required - If set to Yes and the page item is visible, Application Express will automatically perform a NOT NULL validation when the page is submitted. If set to No, no validation a NULL value is accepted.

  • Submit when Enter pressed - If set to Yes, when the user presses the Enter key in the field the page is submitted.

  • Does not save state - If set to Yes, the password is not saved into session state. For security reasons you should always set this attribute to Yes. If you set it to No, consider to set the attribute Store value encrypted in session state to Yes.

  • Authorization Scheme - Optionally select an authorization scheme which must evaluate to TRUE in order for this component to be rendered or otherwise processed.

  • Session State Protection - You can select the level of session state protection by setting this attribute to Unrestricted or Restricted.

    • Unrestricted means the item may be set by passing the item in a URL or in a form. No checksum is required in the URL.

    • Restricted means the item may not be set from a browser. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed, even if Session State Protection is disabled.

  • Store value encrypted in session state - Session state that is sensitive can be encrypted when stored in Application Express session state management tables. To maintain session state encrypted for this item set the value to Yes. To learn more, see "About Session State and Security".

Identifying At Risk Password Items

At risk password items are those that either:

  • Do not use one of the password item types that does not save session state

  • Store the value in session state un-encrypted

Use the Security Profiles and Password Items reports to help identify at risk password items.

Topics:

Viewing the Security Profiles Report

To view the Security Profiles Report:

  1. Navigate to the Workspace home page.

  2. Click the Application Builder icon.

    The Application Builder home page appears.

  3. On the Tasks list, click Cross Application Reports.

  4. Under Security, click Security Profiles report.

    This report list the following information about all applications in the current workspace:

    • Application

    • Name

    • Parsing Schema

    • Application Level Authorization Scheme

    • Authentication

    • Authorization Schemes

    • Authorization Schemes

    • Pages

    • Encrypted Items

    • At Risk Password Items

Viewing the Password Items Report

To identify at risk password items:

  1. Navigate to the Workspace home page.

  2. Click the Application Builder icon.

    The Application Builder home page appears.

  3. On the Tasks list, click Cross Application Reports.

  4. Under Security, click Password Items.

    The Password Items report shows all of the password items within the application and indicates if they use encryption and whether they save state. Password items that do neither are highlighted as At Risk.

Tip:

For pages that contain password items, set page attribute Form Auto Complete to Off. Setting that attribute to Off prevents the Web browser from attempting to auto complete items on the page. To learn more about this attribute, see Table 6-8, "Validation Methods".

About Using Zero as a Session ID

When users access Oracle Application Express application pages, numerous links containing session IDs become visible in the Web browser's location window. If the application is publicly accessible and the user communicates one of these links to another application user, for example by using email or a messaging service, the recipient can use the link and immediately begin sharing the original user's session. This can have a negative effect on both users as they use the application and lead to unpredictable, hard to reproduce screen behavior. To prevent this, Oracle recommends the use of the Zero Session ID feature for all applications where users are not required to provide login authentication. To learn more, see "Facilitating Bookmarks by Using Zero as the Session ID".

Understanding Cross-Site Scripting Protection

Cross site-scripting (also referred to as XSS) is a security breach that takes advantage of dynamically generated Web pages. In a XSS attack, a Web application is sent a script that activates when it is read by a user's browser. Once activated, these scripts can steal data, even session credentials, and return the information to the attacker.

If malicious code were introduced into an Oracle Application Express application, it could be rendered into HTML regions and other places within the application during normal page rendering. To prevent the introduction of malicious code into session state, the Application Express engine escapes characters in certain cases.

Topics:

Protecting HTML Regions and Other Static Areas

In HTML regions and other static display areas, you can reference session state using the &ITEM. notation. Examples of static display areas include HTML regions, page headers and footers, region headers and footers, region titles, button labels, help text, form item labels and post-element text, templates, radiogroup (before and after field text), event success messages, event error messages, navigation bar attributes, application static substitution string values, chart labels and legends, breadcrumbs and list framing text, and calendar text, labels, or legends.

About Safe Item Display Types

When session state is referenced in this way, the value emitted to the page will not have special characters (<, >, &, ") escaped if the referenced item is Display Only with the attribute Save Session State set to No.

If the referenced item has a display type other than Display Only with the attribute Save Session State set to No, the value emitted to the page will have special characters escaped. Although application-level items are also considered to have a safe display type, they do not actually have display properties like form items do.

About the Rules Used to Determine Whether to Escape Values

The Application Express engine uses predefined smart escaping rules to determine if and when to escape values fetched from session state.

The reason for these rules is that items that use the display types listed previously are often for text containing HTML that is intended to be emitted to the browser without being filtered (that is, escaped). The only way this can be made safe is by the enforcement of the rule that these types of items are always escaped on input to the application. For example, if a user passes some text into a safe item using an Oracle Application Express f?p URL syntax, the Application Express engine escapes special characters when saving the value into session state. This has two intended results:

  1. If the value contained no special characters, the value passed in is saved into session state exactly as it was provided.

  2. If the value contained special characters, those characters are escaped when the value is saved into session state.

In either situation, the item can now safely be referenced using an &ITEM. notation in any HTML region or other static area mentioned previously.

Using Safe Item Types to Hold and Emit HTML Markup

You can use the safe item types listed previously to hold and emit HTML markup to the browser. For example, suppose you have a requirement to render some text in bold face by referencing a safe page item named P1_XXX (using &P1_XXX.) The item P1_XXX is presumed to contain the following HTML:

<b>ABABABAB</b>

You can achieve this by using application controls (computations, processes, item source expressions, item default values, and so on) to store values into these safe items. When values are introduced in this way, you ensure the safety of the content. When you use these methods, the Application Express engine does not escape any special characters when saving the values into session state.

Finally, the safety of safe items is ensured by a rule that prevents those items from being posted on a page and submitted to the Application Express engine as part of a page submission.

Protecting Dynamic Output

Items fetched from session state and rendered using htp.p or other methods should be explicitly escaped by the code where it is appropriate to do so. For example, suppose a PL/SQL dynamic content region on a page uses the following:

htp.p(v('SOME_ITEM'));

If the value of the item fetched from session state could contain unintended tags or scripts, you might want to use the following in the region:

htp.p(htf.escape_sc(v('SOME_ITEM'))); 

However, if you are confident that the fetched value is safe for rendering, you do not need to escape the value. As a developer, you need to determine when it is appropriate to not escape output.

As a best practice, follow this rule:

The reason for this is that as a developer, there is no way you can prevent a hacker from posting a malicious value into a non-safe item. Even if your application does not present these items visibly to ordinary users, be aware that a hacker can mount a XSS attack using your application if you do not follow this rule.

Protecting Report Regions

The Application Express engine escapes data rendered in the body of a report. References to session state in report headings and messages are fetched from session state using the smart escaping rules so that the values of safe item types are not escaped and the values of other item types are escaped.

Protecting Form Items

When form items, including hidden items, obtain their values during the generation of the form page to be sent to the browser, the resulting text is escaped before rendering. Some of the safe item types are exceptions to this rule in order to support the intended behavior of each display type.

Some item types have the attribute Escape special characters in the Security region. Use this attribute to specify if the value should be escaped or not. The default is set to Yes. To display HTML code, set this attribute to No.

About Session State and Security

Oracle Application Express persists session state in database tables. Session state is preserved in database tables because it is more secure to store the session state on the server side than on the client. Because Oracle Application Express applications use the stateless HTTP protocol, an application's session state across multiple page views is preserved in database tables. Not maintaining a synchronous database connection for each Oracle Application Express application user significantly lessens memory and database resource requirements.

Developers can query the session state stored by Oracle Application Express applications using the Application Builder and built-in monitoring pages. Developers and administrators can access session state for any application in the workspace to which they are authenticated.

A few best practices for developers include:

  • As a standard part of implementing program control flow, clear the session state of unneeded values using clear-cache page processes or clear-cache directives in URLs used to navigate to pages.

  • Use password page item types that do not save state. This prevents the entered passwords from being saved in session state tables in the database.

  • When sensitive data must persist in a session, it should be saved in Oracle Application Express session state tables in encrypted form. To use this feature, set the page item's Store value encrypted in session state attribute to Yes. Encrypted stored values are automatically decrypted when read.

Note:

The objective of encrypted session state is to persist session state such that the unencrypted values cannot be read by other Oracle Application Express developers or database administrators who might have access to the Oracle Application Express session state tables, debug output, or database data files. Oracle recommends that database backups be performed using facilities that encrypt data in the backup files.

Tip:

You can encrypt item values up to 4000 bytes in length. Attempts to encrypt values longer than 4000 bytes produces an error message.

Understanding Session State Protection

Session State Protection is a built-in functionality that prevents hackers from tampering with the URLs within your application. URL tampering can adversely affect program logic, session state contents, and information privacy.

Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes.

Topics:

How Session State Protection Works

When enabled, Session State Protection uses the Page Access Protection attributes and the Session State Protection item attributes with checksums positioned in f?p= URLs to prevent URL tampering and unauthorized access to and alteration of session state. When Session State Protection is disabled, the page and item attributes related to session state protection are ignored and checksums are not included checksums in generated f?p= URLs.

Enabling Session State Protection

You can enable session state protection from either the Edit Security Attributes page or the Session State Protection page.

Enabling Session State Protection is a two-step process. First, you enable the feature. Second, you set page and item security attributes. You can perform these steps using a wizard, or you can set security attributes for pages and items manually on the Session State Protection page.

Topics:

Enabling Session State Protection from Edit Security Attributes

To enable Session State Protection from the Edit Security Attributes page:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Click the Shared Components icon.

  4. Under Security, click Security Attributes.

  5. Scroll down to Session State Protection and select Enabled from the Session State Protection list.

  6. To configure session Session State Protection, click Manage Session State Protection.

    The Session State Projection page appears.

  7. To enable, disable, or configure Session State Protection using a wizard, click Set Protection.

  8. Otherwise, navigate to the appropriate page or item attributes page and configure the Security attributes.

Tip:

To disable Session State Protection, perform the same steps again, but select Disabled instead of Enabled. Disabling Session State Protection will not change existing security attribute settings, but those attributes will be ignored at run time.
About the Expire Bookmarks Button

Enabling Session State Protection affects whether bookmarked links to the current application will work. Consider the following rules:

  1. Bookmarked links created after Session State Protection is enabled will work if the bookmarked link contains a checksum.

  2. Bookmarked links created before Session State Protection is enabled will not work if the bookmarked link contains a checksum.

  3. Bookmarks that do not contain checksums or contain unnecessary checksums will not be affected by Session State Protection.

During page rendering, the Application Express engine uses a hidden application attribute (a checksum salt) during computation and to verify checksums included in f?p URLs. When you enable Session State Protection, the Application Express engine includes checksums. You can reset the checksum salt attribute by clicking Expire Bookmarks on the Edit Security Attributes page. Note that if you click Expire Bookmarks, bookmarked URLs used to access your application that contain previously generated checksums will fail.

Enabling Session State Protection from Session State Protection

To enable Session State Protection:

  1. Navigate to the Shared Components page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

    The Session State Protection page appears. Note the current Session State Protection status (Enabled or Disabled) displays at the top of the page.

  2. Click the Set Protection button.

    The Session State Protection wizard appears.

  3. Under Select Action, select Enable and click Next.

    Next, determine whether to set security attributes for pages and items.

  4. Select Enable and click Next.

  5. Click Enable Session State Protection.

Tip:

To disable Session State Protection, perform the same steps, but select Disable instead of Enable. Disabling Session State Protection will not change existing security attribute settings, but those attributes will be ignored at run time.

Configuring Session State Protection

Once you have enabled Session State Protection, the next step is to configure security attributes. You can configure security attributes in two ways:

  • Use a wizard and select a value for specific attribute categories. Those selections will then be applied to all pages and items within the application.

  • Configure values for individual pages, items, or application items.

Topics:

Tip:

Before you can configure security attributes, you must first enable Session State Protection. See "Enabling Session State Protection".
Reviewing Existing Session State Protection Settings

You can review a summary of Session State Protection settings for pages, items, and application items on the first page of the Session State Protection wizard.

To view summaries of existing Session State Protection settings:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click Set Protection.

  3. Expand the following reports at the bottom of the page:

Configuring Session State Protection Using a Wizard

When you configure Session State Protection using a wizard, you set a value for specific attribute categories. Those selections are then applied to all pages and items within the application.

To configure Session State Protection using a wizard:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click Set Protection.

    The Session State Protection wizard appears.

  3. Under Select Action, select Configure and click Next.

  4. For Page Access Protection, select one of the following:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • No URL Access - The page may not be accessed using a URL; however, the page may be the target of a Branch to Page branch type, which does not do a URL redirect.

  5. For Application Item Protection, select one of the following:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is also provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

    • Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled.

      Use this attribute for application items or for page items with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

  6. For Page Data Entry Item Protection, select one of the following:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  7. For Page Display-Only Item Protection, select one of the following:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled.

      This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

  8. Click Next.

  9. Click Finish.

Configuring Session State Protection for Pages

To configure Session State Protection for Pages:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Page icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • View Chart. Use this control to view information as a chart.

    • Actions menu - Displays the Actions menu. Use this menu to customize this interactive report. See "Using the Actions Menu".

  4. Select a page number.

    The Set Page and Item Protection page appears. The following information displays at the top of the page:

    • Application ID and name

    • Session State Protection status (Enabled or Disabled)

    • Page Number

    • Page name

  5. For Page Access Protection, select one of the following:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • No URL Access - The page may not be accessed using a URL; however, the page may be the target of a Branch to Page branch type, which does not do a URL redirect.

  6. For Item Types, select Data Entry Items or Display-only Items.

    Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.

  7. If you select Data Entry Items, select a session state protection level for each item:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  8. If you select Display-only Item, select a session state protection level for each item:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  9. Click Apply Changes.

Configuring Session State Protection for Page Items

To configure Session State Protection for items:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Page Item icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "Using the Actions Menu".

  4. Select a page number.

    The Edit Session State Protection for Page and Items page appears. The following information displays at the top of the page:

    • Application ID and name

    • Session State Protection status (Enabled or Disabled)

    • page Number

    • Page name

  5. For Page Access Protection, select a session state protection level for each item:

    • Unrestricted - The page may be requested using a URL with or without session state arguments (Request, Clear Cache, Name/Values).

    • Arguments Must Have Checksum - If Request, Clear Cache, or Name/Value arguments appear in the URL, a checksum must also be provided. The checksum type must be compatible with the most stringent Session State Protection attribute of all the items passed as arguments.

    • No Arguments Allowed - A URL may be used to request the page but no Request, Clear Cache, or Name/Value arguments are allowed.

    • No URL Access - The page may not be accessed using a URL, however the page may be the target of a Branch to Page branch type, which does not do a URL redirect.

  6. For Item Types, select Data Entry Items or Display-only Items.

    Data Entry items are items that can be altered using forms and include hidden items. Display-Only items are rendered only and are not submitted with the form.

  7. If you select Data Entry Items, select a session state protection level for each item:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  8. If you select Display-only Item, select a session state protection level for each item:

    • Unrestricted - The item may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted: May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is always observed, even if Session State Protection is disabled. This attribute may be used with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  9. Click Apply Changes.

Configuring Session State Protection for Application Items

To configure Session State Protection for application items:

  1. Navigate to the Session State Protection page:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. Click Shared Components.

    4. Under Security, select Session State Protection.

      The Session State Protection page appears.

  2. Click the Application Item icon.

  3. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "Using the Actions Menu".

  4. Select an application item.

  5. Under Security, select one of the following from the Session State Protection list:

    • Unrestricted - The item's session state may be set by passing the item name/value in a URL or in a form. No checksum is required in the URL.

      Note: If you need to set this item's value in session state using Ajax, then an Unrestricted protection level must be used for the item (for example in Dynamic Actions, Set Value, Page Items to Submit or Cascading LOVs, Page Items to Submit).

    • Restricted - May not be set from browser - The item may not be altered using the URL or POSTDATA. Use this option when you want to restrict the way that the item value can be set to internal processes, computations, and so on. This attribute is only applicable only to items that cannot be used as data entry items and is always observed even if Session State Protection is disabled. This attribute may be used for application items or for page items with any of these Display As types:

      • Display as Text (escape special characters, does not save state)

      • Display as Text (does not save state)

      • Display as Text (based on LOV, does not save state)

      • Display as Text (based on PLSQL, does not save state)

      • Text Field (Disabled, does not save state)

      • Stop and Start HTML Table (Displays label only)

    • Checksum Required: Application Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the schema is provided. A user-level checksum or a session-level checksum will also suffice (see next bullets). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by any user running the same application in the current workspace but in a different session.

    • Checksum Required: User Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the workspace, application, and user is provided. A session-level checksum will also suffice (see next bullet). Use this option when you want to allow the item to be set only by URLs having checksums that were generated by the same named user, running the same application in the current workspace but in a different session.

    • Checksum Required: Session Level - The item's session state may be set by passing the item name/value in a URL if a checksum specific to the current session is provided. Use this option when you want to allow this item to be set only by URLs having checksums that were generated in the current session.

  6. Click Apply Changes.

Securing File Uploads

Oracle Application Express enables you to easily build an application that can be used to upload files and to access uploaded files. These files are uploaded into a common file storage table. Although the database view APEX_APPLICATION_FILES shows those files associated with your database account (or workspace), programmatic access to the common file storage table does not always require authentication, enabling other users to see your uploaded files. For this reason, Oracle recommends that developers either use the methods described in "About BLOB Support in Forms and Reports" or use the methods described in Oracle Application Express How To Documents for file upload on OTN at:

http://www.oracle.com/technology/products/database/application_express/howtos/index.html

Either of these methods results in the uploaded files being stored in schema tables and not the public table.

See Also:

"Differences Between Page Items and Application Items" and "About Item Types" to learn more about creating a File Browse page-level item

Establishing User Identity Through Authentication

Authentication is the process of establishing each user's identify before they can access your application. Authentication may require a user identify a user name and password or could involve the use of digital certificates or a secure key.

When you create an authentication scheme, you have the option of choosing from a number of preconfigured authentication schemes, copying an authentication scheme from an existing application, or creating your own custom authentication scheme.

Topics:

Understanding How Authentication Works

You determine how your application interacts with users. If all users have the same rights and privileges, they are referred to as public users. However, if your application needs to track each user individually, you need to specify an authentication method.

Authentication establishes the identity of each user who accesses your application. Many authentication processes require that a user provide some type of credentials such as a user name and password. These credentials are then evaluated and they either pass or fail. If the credentials pass, the user has access to the application. Otherwise, access is denied.

Once a user has been identified, the Application Express engine keeps track of each user by setting the value of the built-in substitution string APP_USER. As a user navigates from page to page, the Application Express engine sets the value of APP_USER to identify the user. The Application Express engine uses APP_USER as one component of a key for tracking each user's session state.

From a programming perspective, you can access APP_USER using the following syntax:

  • From PL/SQL:

    V('APP_USER')
    
  • As a bind variable from either PL/SQL or SQL:

    :APP_USER
    

You can use APP_USER to perform your own security checks and conditional processing. For example, suppose you created the following table:

CREATE TABLE my_security_table (
  user_id   VARCHAR2(30),
  privilege VARCHAR2(30));

Once created, you could populate this table with user privilege information and then use it to control the display of pages, tabs, navigation bars, buttons, regions, or any other control or component.

Determining Whether to Include Authentication

As you create your application, you need to determine whether to include authentication. You can:

  • Choose to not require authentication. Oracle Application Express does not check any user credentials. All pages of your application are accessible to all users.

  • Select a built-in authentication scheme. Create an authentication method based on available preconfigured authentication schemes. Depending on which scheme you choose, you may also have to configure the corresponding components of Oracle 10giAS, Oracle Internet Directory, or other external services. See "Using Preconfigured Authentication Schemes" and "Changing the Authentication Scheme Associated with an Application".

  • Create custom authentication scheme. Create a custom authentication method to have complete control over the authentication interface. To implement this approach, you must provide a PL/SQL function the Application Express engine executes before processing each page request. This function's Boolean return value determines whether the Application Express engine processes the page normally or displays a failure page. See "Creating an Authorization Scheme".

Creating an Authentication Scheme

To create an authentication scheme:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

    The Authentication Schemes page appears.

  5. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • View icons. Use this control to toggle between Icons and Report views. To change the view, click these icons:

      • View Icons (default) displays each scheme as a large icon.

      • View Report displays information in a report. To view the events in a flow chart, click the Show icon under the Flow Chart column.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "Using the Actions Menu".

  6. To create a new authentication scheme, click Create.

  7. Specify how the scheme should be created by selecting one of the following:

  8. Follow the on-screen instructions.

Using Preconfigured Authentication Schemes

When you select a preconfigured authentication scheme, Oracle Application Express creates an authentication scheme for your application that follows a standard behavior for authentication and session management.

Topics:

Open Door Credentials

Open Door Credentials enables anyone to access your application using a built-in login page that captures a user name. This authentication method is useful during application development.

Setting Up Open Door Credentials

To set up Open Door Credentials:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select Show Login Page and Use Open Door Credentials.

  8. Specify a login page and click Next.

  9. Enter a name and click Create Scheme.

Oracle Application Express Account Credentials

Oracle Application Express Account Credentials are internal user accounts (also known as "cookie user" accounts) that are created within and managed in the Oracle Application Express user repository. When you use this method, your application is authenticated against these accounts.

See Also:

"Managing Application Express Users" in Oracle Application Express Administration Guide

Application Express Account Credentials is a good solution when:

  • You want control of the user account repository

  • User name and password-based approach to security is sufficient

  • You do not need to integrate into a single sign-on framework

This is an especially good approach when you need to get a group of users up and running on a new application quickly.

Setting Up Application Express Account Credentials

To set up Application Express Account Credentials:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select Show Login Page and Use Application Express Account Credentials.

  8. Specify a login page and click Next.

  9. Enter a name and click Create Scheme.

Database Account Credentials

Database Account Credentials utilizes database schema accounts. This authentication scheme requires that a database user (schema) exist in the local database. When using this method, the user name and password of the database account is used to authenticate the user.

Database Account Credentials is a good choice if having one database account for each named user of your application is feasible and account maintenance using database tools meets your needs

Setting Up Database Account Credentials

To set up Database Account Credentials:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select Show Login Page and Use Database Account Credentials.

  8. Specify a login page and click Next.

  9. Enter a name and click Create Scheme.

LDAP Credentials Verification

You can configure any authentication scheme that uses a login page to use Lightweight Directory Access Protocol (LDAP) to verify the user name and password submitted on the login page.

Application Builder includes wizards and edit pages that explain how to configure this option. These wizards assume that an LDAP directory accessible to your application for this purpose already exists and that it can respond to a SIMPLE_BIND_S call for credentials verification. When you create an LDAP Credentials authentication scheme, the wizard requests and saves the LDAP host name, LDAP port, DN string, whether or not to use SSL, exact DN, and optionally a search filter if not using exact DN. An optional preprocessing function can be specified to adjust formatting of the user name passed to the API.

Setting Up LDAP Credentials Verification

To set up LDAP credentials verification:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select Show Login Page and Use LDAP Directory Credentials.

  8. Specify a login page and click Next.

  9. Specify the following and click Next.

    1. LDAP Host

    2. LDAP Port

    3. Use SSL

    4. Use Exact DN

    5. LDAP Distinguished Name (DN) String

    6. (Optional) Search Filer

    7. (Optional) LDAP Username Edit Function

    To view help for a specific item, click the item label. When help is available, the item label changes to red when you pass your cursor over it and the cursor changes to an arrow and question mark. See "About Field-Level Help".

  10. Enter a name and click Create Scheme.

Note:

If you choose SSL with Authentication as the SSL mode, a wallet must be set up using the Oracle Application Express instance settings. Additionally, the root certification from the LDAP server must be imported into that wallet as a trusted certificate. See "Configuring Wallet Information" in Oracle Application Express Administration Guide and "Using Oracle Wallet Manager" in Oracle Database Advanced Security Administrator's Guide.

DAD Credentials Verification

Database Access Descriptor (DAD) database authentication uses the Oracle database native authentication and user mechanisms to authenticate users using a basic authentication scheme. This authentication scheme gets the user name from the DAD either as the value stored in the DAD configuration or, if the account information is not stored in the DAD configuration, as the user name captured using the basic authentication challenge.

To use DAD credentials verification:

  • Each application user must have a user account in the Oracle database.

  • You must configure a PL/SQL DAD for basic authentication (without account information).

    This results in one user name/password challenge for browser session for your application users. The user identity token is then made available in the APP_USER item.

DAD database authentication is useful when you need to implement an authentication method that requires minimal setup for a manageable number of users. Ideally these users would have self-managed accounts in the database and your use of this authentication method would be short lived (for example, during the demonstration or prototyping stages of development).

The main drawback of this approach is burdensome account maintenance, especially if users do not administer their own passwords, or if their database accounts exist only to facilitate authentication to your application.

Setting Up DAD Credentials Verification

To set up DAD Credentials Verification:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select No Authentication (using DAD).

  8. Enter a name and click Create Scheme.

Single Sign-On Server Verification

Oracle Application Server Single Sign-On verification delegates authentication to the Oracle AS Single Sign-On (SSO) Server. To use this authentication scheme, your site must have been registered as a partner application with the SSO server.

Oracle Application Express applications can operate as partner applications with Oracle Application Server's Single Sign-On (SSO) infrastructure. To accomplish this, you must register your application (or register the Application Express engine) as the partner application. To do so, follow the Oracle Application Server instructions for registering partner applications and install the Oracle 9iAS SSO Software Developer Kit (SDK).

If you choose this approach, your application will not use an integrated login page. Instead, when a user accesses your application in a new browser session, the Application Express engine redirects to the Single Sign-On login page. After the user is authentication by SSO, the SSO components redirect back to your application, passing the user identity and other information to the Application Express engine. The user can then continue to use the application until they log off, terminate their browser session, or until some other session-terminating event occurs.

Setting Up Oracle Application Server Single Sign-On

To set up Oracle Application Server Single Sign-On:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. On the Authentication Schemes page, click Create.

  6. Select Based on a pre-configured scheme from the gallery.

  7. From Gallery, select one of the following:

    • Oracle Application Server Single Sign-On (Application Express engine as Partner App) delegates authentication to the Oracle AS Single Sign-On (SSO) Server. To use this authentication scheme, your site must have been registered as a partner application with the SSO server.

    • Oracle Application Server Single Sign-On (My application as Partner App) delegates authentication to the SSO server. Requires that you register an application with SSO as a partner application.

  8. Enter a name and click Create Scheme.

About Creating an Authentication Scheme from Scratch

Creating an authentication scheme from scratch gives you complete control over your authentication interface. This is the best approach for applications when any of the following is true:

  • Database authentication or other methods are not adequate.

  • You want to develop your own login form and associated methods.

  • You want to delegate all aspects of user authentication to external services such as Oracle 10gAS Single Sign-On.

  • You want to control security aspects of session management.

  • You want to record or audit activity at the user or session level.

  • You want to enforce session activity or expiry limits.

  • You want to program conditional one-way redirection logic before Oracle Application Express page processing.

  • You want to integrate your application with non-Oracle Application Express applications using a common session management framework.

  • Your application consists of multiple applications that operate seamlessly (for example, more than one application ID).

See Also:

"APEX_CUSTOM_AUTH" in Oracle Application Express API Reference

About Session Management Security

When running custom authentication, Oracle Application Express attempts to prevent two improper situations:

  • Intentional attempts by a user to access session state belonging to someone else. However, users can still type in an arbitrary application session ID into the URL.

  • Inadvertent access to a stale session state (probably belonging to the same user from an earlier time). This would commonly result from using bookmarks to application pages.

Oracle Application Express checks that the user identity token set by the custom authentication function matches the user identity recorded when the application session was first created. If the user has not yet been authenticated and the user identity is not yet known, the session state being accessed does not belong to someone else. These checks determine whether the session ID in the request can be used. If not, the Application Express engine redirects back the same page using an appropriate session ID.

Building a Login Page

When you create an application in Oracle Application Express, a login page is created. The alias for the page is 'LOGIN'. You can use this page as the "invalid session page" in an authentication scheme. The page is constructed with processes that call the Oracle Application Express login API to perform credentials verification and session registration.

You can also build your own login pages using the pre-built pages as models and tailoring all of the user interface and processing logic to your requirements.

To create a login page for your application:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Click Create Page.

  4. Select Login Page.

  5. Specify Login page attributes and click Create.

About Deep Linking

Deep linking refers to the ability to link to an Oracle Application Express page out of context (for example, from a hyperlink in an email or workflow notification). When you link to a page out of context and the application requires the user be authenticated, the user will be taken to the login page. After credentials verification, the Application Express engine automatically displays the page that was referenced in the original link. Deep linking is supported for applications that use authentication schemes.

Managing Existing Authentication Schemes

Once created, available authentication schemes display in the Authentication Schemes Repository.

To navigate to the Authentication Schemes Repository:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authentication Schemes.

  5. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • View icons. Use this control to toggle between icon and report views. To change the view, click these icons:

      • View Icons (default) displays each scheme as a large icon.

      • View Report displays information in a report. To view the events in a flow chart, click the Show icon under the Flow Chart column.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "Using the Actions Menu".

  6. To edit a specific authentication scheme, select it.

    The Authentication Scheme page appears.

  7. Edit the appropriate attributes and click Apply Changes.

Viewing the Authentication Scheme Associated with an Application

To view the current authentication scheme for an application:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Click Shared Components.

  4. Under Security, click Security Attributes.

  5. Locate the Authentication section. The current authentication scheme displays next to Authentication Scheme.

  6. To link to the Authentication Scheme pages, select the scheme name.

Changing the Authentication Scheme Associated with an Application

To change the authentication scheme for an application:

  1. Navigate to the Authentication Schemes:

    1. On the Workspace home page, click the Application Builder icon.

    2. Select an application.

    3. On the Application home page, click Shared Components.

      The Shared Components page appears.

    4. Under Security, select Authentication Schemes.

  2. Click the Change Current tab at the top of the page.

  3. From Available Authentication Schemes, select a new authentication scheme and click Next.

  4. Click Make Current.

Viewing Authentication Scheme Utilization Report

The Authentication Schemes report lists authentication scheme utilization for all applications in the current workspace.

To view the Authentication Schemes report:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

    The Application home page appears.

  3. Click Cross Application Reports.

  4. Select Authentication Schemes.

    A report appears displaying each application ID, name, authentication scheme name, status, and description.

Providing Security Through Authorization

Authorization is a broad term for controlling access to resources based on user privileges. While conditions control the rendering and processing of specific page controls or components, authorization schemes control user access to specific controls or components.

Topics:

How Authorization Schemes Work

An authorization scheme extends the security of your application's authentication scheme. You can specify an authorization scheme for an entire application, page, or specific control such as a region, item, or button. For example, you could use an authorization scheme to selectively determine which tabs, regions, or navigation bars a user sees.

An authorization scheme either succeeds or fails. If a component or control level authorization scheme succeeds, the user can view the component or control. If it fails, the user cannot view the component or control. If an application or page-level authorization scheme fails, then Oracle Application Express displays a previously defined message.

When you define an authorization scheme, you give it a unique name. Once defined, you can attach it to any component or control in your application. To attach an authorization scheme to a component or control in your application, simply navigate to the appropriate attributes page and select an authorization scheme from the Authorization Scheme list.

Creating an Authorization Scheme

Before you can attach an authorization scheme to an application or an application component or control, you must first create it.

To create an authorization scheme:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authorization Schemes.

  5. Click Create.

  6. Specify how to create an authorization scheme by selecting one of the following:

    • From Scratch

    • As a Copy of an Existing Authorization Scheme

  7. Follow the on-screen instructions.

Editing Attributes of an Existing Authorization Scheme

To edit attributes of an existing authorization scheme:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authorization Schemes.

    The Authorization Schemes page appears. By default, each scheme displays as an icon.

  5. You can customize the appearance the page using the Search bar at the top of the page. Available controls include:

    • Search icon - Resembles a magnifying glass. Click this icon to narrow your search to only specific columns. To search all columns, select All Columns.

    • Text area - Enter case insensitive search criteria (wild card characters are implied) and then click Go.

    • Go button - Executes a search or applies a filter.

    • View icons. Use this control to toggle between icon and report views. To change the view, click these icons:

      • View Icons (default) displays each scheme as a large icon.

      • View Report displays information in a report. To view the events in a flow chart, click the Show icon under the Flow Chart column.

    • Actions menu - Displays the Actions menu. Use this menu to customize the report view. See "Using the Actions Menu".

About the Evaluation Point Attribute

You can specify when your authorization scheme is validated in the Evaluation Point attribute. You can choose to have your authorization scheme validated once for each session or once for each page view.

Keep in mind, if you specify that an authorization scheme should be evaluated once for each session and the authorization scheme passes, the underlying code, test, or query will not be executed again for the duration of the application session. If your authorization scheme consists of a test whose results might change if evaluated at different times during the session, then you should specify that the evaluation point be once for each page view.

About Resetting Authorization Scheme State

If an authorization scheme is validated once for each session, Oracle Application Express caches the validation results in each user's session cache. You can reset a session's authorization scheme state by calling the APEX_UTIL.RESET_AUTHORIZATIONS API.

Calling this procedure nulls out any previously cached authorization scheme results for the current session. Be aware that this procedure takes no arguments and is part of the publicly executable APEX_UTIL package.

See Also:

"RESET_AUTHORIZATIONS Procedure" in Oracle Application Express API Reference

Attaching an Authorization Scheme to an Application, Page, or Components

Once you have created an authorization scheme you can attach it to an entire application, page, control, or component.

Topics:

Attaching an Authorization Scheme to an Application

To attach an authorization scheme to an application:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Click the Shared Components icon.

    The Shared Components page appears.

  4. Under Security, click Security Attributes.

  5. Scroll down to Authorization and make a selection from the Authorization Scheme list.

Attaching an Authorization Scheme to a Page

To attach an authorization scheme to a page:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Select a page.

  4. Under Page Rendering, locate the section with the title of Page.

    Description of pg_def_edit_pg_att.gif follows
    Description of the illustration pg_def_edit_pg_att.gif

  5. Click Edit page attributes icon.

  6. Scroll down to Security and make a selection from the Authorization Scheme list.

Attaching an Authorization Scheme to a Control or Component

To attach an authorization scheme to a page component or control:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. Select a page.

  4. Click the name of the component or control to which you want to apply the authorization scheme.

  5. Scroll down to Security and make a selection from the Authorization Scheme list.

Viewing Authorization Reports

You can use the Authorization Scheme Subscription and Authorization Scheme Utilization reports to better manage authorization schemes within your application.

To view authorization scheme reports:

  1. On the Workspace home page, click the Application Builder icon.

  2. Select an application.

  3. On the Application home page, click Shared Components.

    The Shared Components page appears.

  4. Under Security, select Authorization Schemes.

  5. Click the appropriate tab at the top of the page:

    • Subscription

    • Utilization

Subscription

Use the Authorization Scheme Subscription report to view details about authorization schemes subscription.

Utilization

Use the Authorization Scheme Utilization report to view details about authorization schemes utilization.

To view additional reports indicating which pages having authorization schemes and which do not, select one of the following from the Tasks list:

  • Report Pages With Authorization Schemes

  • Report Pages Without Authorization Schemes