9 Using Forms Services with Oracle Access Manager

Oracle Access Manager 11g, a component of Oracle Fusion Middleware 11g, is a Single Sign-On solution for authentication and authorization. Information is provided about enable Single Sign-On protection for Forms applications, forms services features with authentication server protection, protecting forms applications with single sign-on and integrating oracle forms and reports.

The following sections are included in this chapter:

9.1 Oracle Access Manager and Single Sign-On

Oracle Forms Services applications in Oracle FMW 12c can be protected by Oracle Access Managed (OAM) 11gR2 patch set 3.

Oracle Access Manager 11g is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides restricted access to confidential information and centralized authentication and authorization services. Oracle Access Manager 11g, a component of Oracle Fusion Middleware 11g, is a Single Sign-On solution for authentication and authorization.

Authentication servers enable an application to authenticate users by means of a shared authentication token or authentication authority. That means that a user authenticated for one application is automatically authenticated for all other applications within the same authentication domain.

Forms applications use a single sign-on solution only for obtaining database connection information from Oracle Internet Directory or Oracle Platforms Security Services (OPSS). Once the database information is obtained, interaction with the authentication server no longer occurs. Exiting a Forms application does not perform a single sign-on logout unless the application has been coded with one of the SSO logout features introduced in Oracle Forms 12c. Conversely, logging out of a single sign-on session does not terminate an active Forms session unless the application has been coded with one of the SSO logout features introduced in Oracle Forms 12c. The database session exists until the Forms Runtime (for example, frmweb.exe) on the server terminates, usually by explicitly exiting the form.

Authentication servers users can use to authenticate other applications that are not Oracle products, for example, custom-built Java EE applications.

Oracle Forms Services provides out-of-the box support for single sign-on for as many Forms applications as run by the server instance with no additional coding required in the Forms application.

Note:

Oracle Forms Services applications run in a single sign-on environment using the OID (or OPSS) and authentication server combinations. Supported versions can be found in the Product Certification Guide.

For information about:

Certifications, see Oracle Fusion Middleware Supported System Configurations.
Oracle Access Manager, see Understanding Single Sign-On with Access Manager.
Oracle Internet Directory, see Configuring SSO Providers for Oracle Identity Manager.
Oracle Platform Security Services, see Introduction to Oracle Platform Security Services.

9.1.1 Single Sign-On Components used by Oracle Forms

There are various Single Sign-On components in Oracle Fusion Middleware that are involved when running Forms applications in single sign-on mode with an authentication server.

The following figures, describes the high level overview of the various components involved in the single sign-on deployment setup of Forms Services.

Figure 9-1 Components involved in the Single Sign-On Deployment Setup of Forms Services with OPSS as the Forms Identity Store

Description of "Figure 9-1 Components involved in the Single Sign-On Deployment Setup of Forms Services with OPSS as the Forms Identity Store"

Figure 9-2 Components involved in the Single Sign-On Deployment Setup of Forms Services with (Oracle Internet Directory) OID Identity as the Forms Identity Store

Description of "Figure 9-2 Components involved in the Single Sign-On Deployment Setup of Forms Services with (Oracle Internet Directory) OID Identity as the Forms Identity Store"

Following is the description of the components mentioned in the above figure:

Authentication Server
- Oracle Access Manager (OAM Server) - Oracle FMW 11g authentication server that a full range of security functions that include Web single sign-on, authentication and authorization. When running Forms Services, Oracle Internet Directory as the Identity Store. Oracle Access Manager can use webgate as the access client configured with Oracle HTTP Server.
Access Client
- webgate - WebGate provides single sign-on support. It intercepts incoming HTTP requests and forwards them to the Access Server for authentication. Oracle Forms Services and Oracle Reports Services can use webgate as an access client with OAM server.

Forms Identity Store
- It is the storage for Forms Resource Access Descriptors, which contains the Forms Server database connection information. Oracle Platform Security Services (OPSS) or Oracle Internet Directory (OID) can be used as a Forms Identity Store. Oracle Platform Security Services (OPSS) is set as the default Forms Identity Store, but Forms administrators can use Oracle Enterprise Manager to change the Forms Identity Store to Oracle Internet Directory (OID) and back to Oracle Platform Security Services.
OAM Server Identity Store - Oracle Internet Directory (OID) is an LDAP server that is used as the Identity store by the Oracle Access Manager (OAM) authentication server and the Forms applications

Note:

When Oracle Internet Directory (OID) is used as the Forms Identity Store, the same Oracle Internet Directory (OID) instance should be set as the Oracle Access Manager's primary identity store.
Forms Servlet - The Oracle Forms Services component accepts the initial user request to start a Forms application. The Forms servlet detects if an application requires authentication, directs the request to the authentication server and accesses the Oracle Internet Directory to obtain the database connect information.

9.1.2 Authentication Flow

The following figures describes the authentication flow of authentication server support in Oracle Forms, the first time the user requests an application URL that is protected by authentication server:

Figure 9-3 Authentication Flow for First Time Client Request

Description of "Figure 9-3 Authentication Flow for First Time Client Request"

Figure 9-4 Authentication Flow for First Time Client Request

Description of "Figure 9-4 Authentication Flow for First Time Client Request"

The steps description the authentication flow mentioned in the above figure:

The user requests a Forms URL similar to http(s)://<hostname>:<port>/forms/frmservlet?config= <application>&...

Note:

Use the HTTP port number in the Forms URL for Forms applications that use single sign-on. The Forms URL is similar to http://<host name>:<http port>/forms/frmservlet?config=ssoapp where soap is the name of the section in forms configuration file with single sign-on (ssoMode) enabled.
The Forms servlet redirects the user to the authentication server login page.
The user provides user name and password through the login form.
The password is verified through Oracle Internet Directory (LDAP Server).
The user is redirected to the URL with sso_userid information.
The Forms servlet retrieves the database credentials from Forms Identity Store.
The Forms servlet sets the sso_userid parameter in the Run form session and permits the applet to connect to the Forms listener servlet.
The Forms servlet starts the Forms server.

Figure 9-5 describes the authentication flow of single sign-on support in Oracle Forms Services when a user, authenticated through another partner application, requests an application that is protected by authentication server.

Figure 9-5 Authentication Flow for Subsequent Client Requests

Description of "Figure 9-5 Authentication Flow for Subsequent Client Requests"

The steps description the authentication flow mentioned in the above figure:

The user requests the Forms URL.
The Forms servlet redirects the user to the authentication server and its login page.
The user is redirected to the URL with the sso_userid information.
The Forms servlet retrieves the database credentials from the Forms Identity Store.
The Forms servlet sets the sso_userid parameter in the Runform session and the applet connects to the Forms listener servlet.
The Forms servlet starts the Forms server.

9.2 Setup Process

Single Sign-On is not enabled out of the box for Forms applications.

The following step is required to enable Single Sign-On protection for Forms applications.

Enabling SSO for Forms Application after Configuring Forms Service 12c Weblogic Domain

9.2.1 Enabling SSO for Forms Application after Configuring Forms Service 12c Weblogic Domain

Single sign-on (SSO) can be enabled for Forms Applications after setting up the 12c Forms Services Weblogic Domain and after configuring a Web-tier instance in the Domain.

The following flowchart describes the steps to enable SSO for Forms application post installation.

Figure 9-6 Enabling SSO for Forms application post installation

Description of "Figure 9-6 Enabling SSO for Forms application post installation"

The steps depicted in the flowchart are described in the following table:

Table 9-1 Tasks to Enable Single Sign-On for Forms Application Post installation

Tasks	Options	Description	Comments
Prerequisite	No	Create a Web-tier (OHS) instance in the Weblogic Domain and enable Web-tier (OHS) to Forms managed server routing.
Task 1: Make a decision if you want to enable single sign-on Protection for Forms applications.	No	User has opted to run Forms applications without single sign-on protection.
	Yes	User has opted to run Forms with single sign-On server with Oracle Access Manager (OAM Server) as the authentication server.	For detailed steps for installing OAM, see Oracle Fusion Middleware Installation Guide for Oracle Forms and Reports.
Task2: Select the partner application registration approach.	Use frmconfighelper script	User has opted to use frmconfighelper script to register the web-tier instance as the partner application with Oracle Access Manager (OAM Server).	For detailed steps, see Registering web-tier instance as OAM partner application and OAM policy configuration.
	Use OAM Admin Console	User has opted to use OAM Console to do register the web-tier instance as the partner application with Oracle Access Manager (OAM Server).	For detailed steps, see Registering web-tier instance as OAM partner application and OAM policy configuration.
Task 3: Restart the Web-tier instance and Admin Server instance		The Web-tier instance and the WLS Admin server have to be restarted to replicate WebGate configuration to the web-tier runtime instances.
Task 4: Choose the Forms Identity Store type for storing Resource Access descriptors.	Oracle Platform Security Services (OPSS)	Oracle Platform Security Services (OPSS) is configured as the default Forms Identity Store, so no action is required.	For detailed steps see Selecting Oracle Internet Directory or Oracle Platform Security as the Forms Identity Store.
	Oracle Internet Directory (OID)	The user opted to use Oracle Internet Directory (OID) as the Forms Identity Store.	For detailed steps on Forms Oracle Internet Directory (OID) association and enabling Oracle Internet Directory (OID) as the Forms Identity store see Configuring Forms J2EE application with Oracle Internet Directory.
Task 5: Enable SSO for Forms applications in formsweb.cfg	This task is mandatory.	After having registered the Access client with the authentication server, the user must enable SSO for Forms applications.	For detailed steps for enabling SSO for Forms applications in formsweb.cfg, see Protecting Forms applications with Single Sign-On.

9.3 Forms Services Features with Authentication Server Protection

In this release of Oracle Forms Services specific features and enhancements are available for Authentication Server Protection.

The following are the features and enhancements:

9.3.1 Dynamic Resource Creation

In single-sign on mode, when a user tries to connect to a Forms application, the user is authenticated by webgate in combination with an authentication server and Forms Identity Store. Once the user is authenticated, the user is directed to the Forms servlet which takes the user's request information containing the single sign-on user name. The user name and the application name build a unique pair that identifies the user's resource information for this application in Forms Identity Store.

When an authorized Forms user has neither the resource for a particular application that is being requested nor a default resource in Forms Identity Store, then the user is redirected to the Forms RAD Servlet for the creation of the Resource Access Descriptor. After creating the resource, the user is redirected to the original Forms request URL.

The way Oracle Forms Services handles the missing resource information can be customized by the application or Oracle Forms Services administrator. The following options are available:

Allow dynamic resource creation (default)
Redirect the user to a pre-defined URL as specified by the ssoErrorUrl parameter
Display the Forms error message

The redirection URL is provided by the system administrator in the Forms configuration files and should be either absolute or relative.

9.3.2 Support for Dynamic Directives

Enforcing single sign-on in Forms is done within the formsweb.cfg file. The single sign-on parameter, ssoMode, when set to a valid value other than FALSE, indicates that the application requires authentication by authentication server.

This parameter allows a Forms Services instance to handle both application types, those that rely or do not rely on single sign-on for retrieving the database password. Because single sign-on is configured in the formsweb.cfg file, Fusion Middleware Control users can use to manage this aspect of authentication.

9.3.3 Support for Database Password Expiration

In Oracle Forms Services 12c, if the database password has expired and the Forms Services application, running in single sign-on mode, helps to renew it, the new password entered by the user updates the Resource Access Descriptor (RAD) in Forms Identity Store for this application. This feature ensures that authenticating a Forms user via authentication server with Forms continues to work even when the user's database password has changed. However, if password changes are made in SQL*Plus, and not in Oracle Forms, the database connect string is not updated in the Forms Identity Store.

9.4 Protecting Forms applications with Single Sign-On

Oracle Forms applications are configured using a central configuration file, the formsweb.cfg file in the $DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config directory. The recommended method of managing formsweb.cfg file is using Fusion Middleware Control.

The following parameters defined in Oracle Forms Services configuration file formsweb.cfg is necessary for the users to enable Single Sign-On in individual or collective Forms applications. It is recommended that this file should be managed using the Fusion Middleware Control.

Table 9-2 Parameters used to enable single Sign-On

Parameter Name	Valid values	Default Value
ssoMode	true webgate false	false
ssoProxyConnect	yes no	yes
ssoDynamicResourceCreate	true false	true
ssoErrorUrl	String URL
ssoCancelUrl	String URL

Note:

A detailed description of these parameters along with their possible values are discussed below.

These Oracle Forms parameters in the formsweb.cfg file are set in the User Parameter section, which define the behavior for all Forms applications run by the server. These parameters can also be set in a Named Configuration, which define the settings for a particular application only. A single sign-on parameter set in a Named Configuration section overrides the same parameter set in the User Parameter section.

To enable single sign-on for an application:

Start Fusion Middleware Control.
Select Web Configuration from the Forms menu.
Select the row that lists the configuration section for your application.
In the Section region, select sso in the Show drop down list.
In the Section region, select the row containing ssoMode.
In the Value field, enter webgate or TRUE.
Click Apply to update the formsweb.cfg file.

Single sign-on is now enabled for the selected application.

To disable single sign-on for an application:

Select Web Configuration from the Forms menu.
Select the row that lists the configuration section for your application.
In the Section region, select sso in the Show drop down list.
In the Section region, select the row containing ssoMode.
In the Value column, enter FALSE.
Click Apply.

Single sign-on is now disabled for the selected application.

9.4.1 ssoMode

The ssoMode parameter enables a Oracle Forms Services application to connect to an authentication server. Following are the values that the single sign-on parameter, ssoMode can assume:

ssoMode, when set to TRUE or webgate indicates that the application requires authentication by OAM Server using webgate as the access client. Webgate must be manually configured.
ssoMode, when set to FALSE indicates that the application does not require authentication with an authentication server.

By default, Oracle Forms applications are not configured to run in single sign-on mode. The ssoMode parameter can be set in two places in the formsweb.cfg file:

By setting ssoMode in the default section of formsweb.cfg with a value of true or webgate which allows all applications to run in single sign-on mode by this Oracle Forms Services instance
By setting the ssoMode parameter in a named configuration of an Oracle Forms application which enables or disables single sign-on only for this particular application, for example:

[myApp]

form=myFmx

ssoMode=true

9.4.2 ssoProxyConnect

The ssoProxyConnect parameter enables a user to control when Oracle Forms should use a proxy connection to the database and when it should not. The ssoProxyConnect parameter can be set in two ways:

By setting ssoProxyConnect in the default section of formsweb.cfg with a value of yes which allows all applications to run in single sign-on mode by this Oracle Forms Services instance
By passing the ssoProxyConnect parameter in the URL at runtime, for example http://<host>:<port>/?config=myapp&……&ssoProxyConnect=yes

9.4.3 ssoDynamicResourceCreate

The ssoDynamicResourceCreate parameter is set to true by default which allows the user to create a Resource Access Descriptor (RAD) entry in OPSS (depending on how you have configured) to run the application if this resource entry does not exist.

Allowing dynamic resource creation simplifies administration because there is no longer the need for an administrator to create user RAD information in advance. The ssoDynamicResourceCreate parameter can be set as a system parameter in the formsweb.cfg file or as a parameter of a named configuration. Because the default is set to true, this parameter may be used in a named configuration for a specific application to handle a missing RAD entry differently from the default.

Notice that enabling an application for single sign-on with the value of the ssoDynamicResourceCreate parameter set to false, while not specifying a value for the ssoErrorURL, causes Oracle Forms to show an error message if no RAD resource exists for the authenticated user and this application.

Since not all administrators want their users to create resources for themselves these parameters allow administrators to control Forms Identity Store resource creation. Although the default behavior is to direct users to an HTML form that allows them to create the resource, the administrator can change the setting and redirect the user to a custom URL.

For the configuration section for the Forms application, you need to set these parameters:

[myApp]

form=myFmx

ssoMode=true

ssoDynamicResourceCreate=false

For information about setting these parameters through Enterprise Manager Fusion Middleware Control, see Managing Parameters.

9.4.4 ssoErrorURL

The ssoErrorURL parameter allows an administrator to specify a redirection URL that handles the case where a user RAD entry is missing for a particular application. This parameter has effect only if the ssoDynamicResourceCreate parameter is set to false, which disables the dynamic resource creation behavior. The ssoErrorURL parameter can be defined in the default section and as a parameter in a named configuration section. The URL can be of any kind of application, a static HTML file, or a custom Servlet (JSP) application handling the RAD creation, as in the example below.

[myApp]
form=myFmx
ssoMode=true
ssoDynamicResourceCreate=false
ssoErrorURL=http://example.com:7779/servlet/handleCustomRADcreation.jsp
…

9.4.5 ssoCancelUrl

The ssoCancelURL parameter is used in combination with the dynamic RAD creation feature (ssoDynamicResourceCreate= true) and defines the URL that a user is redirected to if the user presses the cancel button in the HTML form that is used to dynamically create the RAD entry for the requested application.

9.4.6 Accessing Single Sign-on Information From Forms

Optionally, if you need to work with authentication server to authenticate information in a Forms application, the GET_APPLICATION_PROPERTY() Built-in you can use to retrieve the following login information: single sign-on user ID, the user distinguished name (dn), and the subscriber distinguished name (subscriber dn)

authenticated_username := get_application_property(SSO_USERID);
userDistinguishedName := get_application_property(SSO_USRDN);
subscriberName := get_application_property(SSO_SUBDN);
config := get_application_property(CONFIG).

The Forms application developer can obtain the SSO information such as single sign-on user ID, subscriber distinguished name (subscriber dn), and user distinguished name (dn) in SSO mode with either OracleAS Single Sign-On server or Oracle Access Manager when using webgate as the access client.

SSO_USERDN and SSO_SUBDN properties will not be available through the GET_APPLICATION_PROPERTY() Built-in when using Oracle Platform Security Services (OPSS) as the Identity Store for storing Forms application RADs.

Note:

config can be obtained even in non-SSO mode.

9.5 Integrating Oracle Forms and Reports

Oracle Reports is installed with authentication server enabled. The best practice for Oracle Forms applications calling integrated Oracle Reports is to use the Oracle Forms Built-in, RUN_REPORT_OBJECT.

When requesting a report from an SSO-enabled Oracle Forms application, the authenticated user's SSO identity is implicitly passed to the Reports Server with each call to RUN_REPORT_OBJECT built-in. The SSO identity authenticates the user to the Reports Server for further authorization checking, if required.

A Forms application running in non-SSO mode can run a report on a SSO-secured Reports Server, but fails if the Reports Server requires authorization. Also, users must provide their SSO credentials when retrieving the Reports output on the Web.

For information about:

Enabling single sign-on in Forms, see Protecting Forms applications with Single Sign-On.
Configuring single sign-on in Reports, see Configuring and Administering Oracle Single Sign-On.
Integrating Oracle Forms and Oracle Reports, see Forms and Reports 12c Integration White Paper

Note:

Beginning with Oracle Forms and Reports 12c, integration with Reports from Forms will require that the environment variable COMPONENT_CONFIG_PATH be set in the Forms Environment configuration (default.env). The value should be set to the path of

DOMAIN_HOME/config/fmwconfig/components/ReportsToolsComponent/<reports_tools_component_name>

9.5.1 Integrating Forms and Reports Installed in Different Instances

Beginning in 11g, Forms and Reports can be configured separately in different instances. If you chose to install Forms and Reports in different Oracle instances, and later require Forms and Reports integration, you need to manually configure files required to establish communication with Reports Servers, as described in Communication Between Reports and Forms Installed on Different Instances.

9.5.2 Integrating with Secured Reports Server without SSO

Support has been added for RUN_REPORT_OBJECT failures when Reports server is secured without SSO.

RUN_REPORT_OBJECT is used in Forms to send requests to the Reports Server. REPORT_OBJECT_STATUS is used to check the status of a requested report. Typically the return value of RUN_REPORT_OBJECT is <servername>_<jobid>. Previously, requests could only be sent to Reports Servers that were either not secured or secured using SSO. When connecting to a Reports Server that was secured without SSO, REPORT_OBJECT_STATUS calls failed.

It is now possible to connect with Reports Servers that are secured without SSO. When a request is sent to a Reports Server secured without SSO, the return value of RUN_REPORT_OBJECT is <servername>_<jobid>#<authid>. For an unsecured or SSO secured Reports Server, the return value of RUN_REPORT_OBJECT is still <servername>_<jobid>. Users generally extract jobid from the RUN_REPORT_OBJECT return value in PL/SQL. Therefore, the method to obtain a jobid is different if the Reports Server is secured without SSO.

9.6 Enabling and Configuring Proxy Users

Oracle Database supports proxy user authentication, which allows a client user to connect to the database through an application server, as a proxy user.

This section contains the following:

9.6.1 Proxy User Overview

Many large applications, including Oracle's own E-Business Suite, use a single username for all connections. This makes it possible to manage users in a way that often suits large companies better but it creates a problem with auditing. All inserts, updates and removals of records appear, from the database's perspective, to have been done by a single user. To restore auditing, the application developers must write and implement customized auditing code in the database that requires a user name to be passed to the database from the application. This step not only takes development time, but also duplicates functionality that is already implemented in the Oracle Database.The second issue is security. If that single user access is ever compromised, the compromised user will have access to the entire application schema.To address these two issues, Oracle Database supports proxy user authentication, which allows a client user to connect to the database through an application server, as a proxy user.

The following figure describes the authentication of a Forms proxy user.

Figure 9-7 Proxy User Authentication

Description of "Figure 9-7 Proxy User Authentication"

Oracle Forms authenticates the user through Oracle Internet Directory or LDAP, as shown in the center of the image.
Forms then connects as the proxy user with or without a password, passing in the real username from the Oracle Internet Directory repository.
Typically, the proxy user is configured with least set of privileges. In the following procedure, the proxy user has "connect" and "create session" privileges.
The database accepts the create session action for the proxy user and uses the real username in audits and access control.
The Oracle Internet Directory user cannot connect to the database independently without configuration of the proxy user account.
The proxy user account isolates the client from direct SQL*Plus connections.

9.6.2 Enabling Proxy User Connections When Enabling SSO with Oracle Internet Directory

To use a proxy support in Forms, you first need to create a proxy user.

In this example, the proxy user is called midtier:

Create a proxy user in the database.

SQL> CREATE USER midtier IDENTIFIED BY midtierPW;

Assign connect and create session privileges to midtier:
```
SQL> GRANT CONNECT,CREATE SESSION TO midtier; 
```
At this point, this proxy user has connect and create session privileges and has no grants on any of the user schemas.
Create a database user which has one-to-one mapping with a SSO username (that is, if appuser is the SSO username create database user appuser).
```
SQL> CREATE USER appuser IDENTIFIED BY appuserPW;
```
Assign create session privileges to appuser.
```
SQL> GRANT CREATE SESSION TO appuser; 
```
To make it possible to connect through the midtier user you need to alter the database user:
```
SQL> ALTER USER appuser GRANT CONNECT THROUGH midtier;
```
The user appuser can now connect through the midtier account.

Alternatively, you can define the roles that the proxy user can connect to the database as
```
SQL> ALTER USER appuser GRANT CONNECT THROUGH midtier WITH ROLE <role_name>;
```
Repeat Step 3 and 4 for all database users who need to use the proxy user account.

It is also possible to set up the database users in Oracle Internet Directory with the help of the database functionality called Enterprise User Security. If you choose this method, the proxy user is the only user defined in the database and the additional benefit of easy administration is gained, see Configuring Directory Server Chaining in Administering Oracle Internet Directory.

The application user's password is not presented to the database; only the user name and the proxy user's user name and password. Forms, with the help of OCI calls, issues the equivalent of:

SQL> connect midtier[appuser]/midtierPW@databaseTnsName

For example, suppose your application always connects to the database using midtier. This midtier now informs the database that the actual user is appuser. Without using proxy users, the SQL command select USER from DUAL would return midtier, but, using proxy users, this query returns appuser. This essentially tells the database to trust that the user is authenticated elsewhere and to let the user connect without a password and to grant the connect role.

Note:

In the Step 3 of the above procedure, the database users are typically configured to have a subset of permissions granted to a schema. For example, appuser is granted CREATE permissions to the schema app_schema with the SQL command:
```
SQL> GRANT CREATE ON SCHEMA app_schema TO appuser
```
Thus, the appuser is restricted to perform only a set of actions in proxy user mode.
When the database user (for example, appuser) is connected in proxy mode, user actions of the database users are audited rather than that of the proxy user, see Managing Security for Oracle Database Users.

9.6.3 Enabling SSO for Proxy Users

Create a configuration section in formweb.cfg for single sign-on (for example, ssoapp) and set SSOProxyConnect to yes and ssoMode to true or webgate.

The username and password that is used for the proxy connection is defined in the RAD entry for the user that is logging on. If ssoProxyConnect=yes, the connect string equivalent issued by Forms is in effect:

SQL> connect RADUsername[appuserName]/RADPassword@databaseTnsName

9.6.4 Accessing the Forms Application

After enabling proxy user connections and single sign-on, perform the following steps to access the forms applications:

Run the forms application with the URL http://<host name>:<http port>/forms/frmservlet?config=ssoapp where ssoapp is the name of the configuration section with single sign-on (ssoMode) is enabled.
Use the single sign-on user name and password to log in.

In this example, as described in Enabling Proxy User Connections When Enabling SSO with Oracle Internet Directory, the single sign-on username is appuser and password is appuserPW.

9.6.5 Changes in Forms Built-ins

The Built-in get_application_property now takes a new parameter called IS_PROXY_CONNECTION (a Boolean). When this parameter is supplied, the call returns true if the form is running in proxy user mode, false otherwise.

Note:

When using Oracle Platform Security Services (OPSS) as the Forms Identity Store and if SSO_USERDN or SSO_SUBDN parameter is passed to get_application_property built-in, it will return an empty String. These parameters are valid only when running with Oracle Internet Directory as the Forms Identity store.

9.6.6 Reports Integration with Proxy Users

The integration with Reports is maintained when a proxy user is used in Forms. The Oracle Reports administrator has to set up a proxy user. Ensure that the following configuration has been completed in the Reports configuration files.

In rwserver.conf, enter the Forms configuration section name (frm_config_name) and database SID name that is configured for proxy user support (dbname).

<dbProxyConnKeys>

<dbProxyKey name="frm_config_name" database="dbname"/>

</dbProxyConnKeys>

In rwservlet.properties, ensure that Proxy mode is enabled.

<enabledbproxy>yes</enabledbproxy>

For information about Reports configuration files, see Configuring Oracle Reports Services.

9.7 Post installation Configuration

This section describes specific post installation steps.

These steps are required to perform depending on the choices made in Setup Process.

The following sections are included:

9.7.1 Configuring Forms J2EE application with Oracle Internet Directory

The users connecting through a Forms application as proxy users must also be defined in authentication server and Oracle Internet Directory. Oracle Forms authenticates the user via authentication server (using authentication server with Forms is a requirement when using a proxy user). Oracle Forms then connects to the database as the proxy user with a username and password that is in the RAD for the Oracle Internet Directory entry for the application user.

To access the Associate/Disassociate page:

Start Fusion Middleware Control.
Navigate to the Forms Home page.
From the Forms menu, select Forms Runtime LDAP Associations.

The Forms Runtime LDAP Associations page is displayed.

Figure 9-8 Forms Runtime LDAP Associations

Description of "Figure 9-8 Forms Runtime LDAP Associations"

To associate OID Host with a Forms Application:

To associate an Oracle Internet Directory host with a Forms application for the first time, from the Associate/Disassociate OID page, select the Forms application. Click Associate.

The Associate dialog appears.
Enter the Oracle Internet Directory Host details as described in the following table.

Click Associate.

The Associate/Disassociate OID page reappears.

Table 9-3 Oracle Internet Directory Host Details

Parameter	Description
OID Host	Select the Oracle Internet Directory Host from the list or select New Oracle Internet Directory (OID) host to add new host details.
New OID host	Host name of the Oracle Internet Directory server. This field is enabled if you have selected to add new Oracle Internet Directory (OID) Host.
New OID Port	Port number on which Oracle Internet Directory is listening. This field is enabled if you have selected to add new Oracle Internet Directory Host.
Username	Oracle Internet Directory Administrator username
Password	Oracle Internet Directory Administrator password
Use SSL Port	Select this box if the connection to the Oracle Internet Directory Host should use SSL (in which case the port number provided should be the SSL port).

To Disassociate OID Host from a Forms Application:

From the Associate/Disassociate OID page, select the Forms application. Click Disassociate.

A confirmation box appears.
Click Yes.

The Oracle Internet Directory host is disassociated from the Forms application.
Restart the Oracle WebLogic Managed Server and the front-end OHS for the changes to take effect.

To prevent users from being inadvertently disconnected from active forms sessions, ensure you choose to restart Oracle WebLogic Managed Server and the front-end OHS at a convenient time when users are not running any forms sessions.

To re-associate an OID Host with a Forms Application:

From the Associate/Disassociate OID page, select the Forms application. Click Disassociate.
From the Associate/Disassociate OID page, select the Forms application. Click Associate.

Enter the Oracle Internet Directory Host details as described in the above table.
Generate and apply the access client file.

Access client file, as described in Selecting Oracle Internet Directory or Oracle Platform Security as the Forms Identity Store

9.7.2 Selecting Oracle Internet Directory or Oracle Platform Security as the Forms Identity Store

Oracle Platform Security Services (OPSS) is the set default Forms Identity Store. If the administrator performs the Forms OID association, it will set Oracle Internet Directory as the Forms Identity Store. Users can switch back to Oracle Platform Security Services (OPSS) as Forms Identity Store by un-checking the check box in the Primary Identity Store column for each deployment on Forms Runtime LDAP Associations page.

9.7.3 Registering web-tier instance as OAM partner application and OAM policy configuration

Users have two choices for registering the web-tier instance as the Oracle Access Manager (OAM) partner application and configure the resulting OAM policy.

frmconfighelper script
OAM console

Note:

The Web-tier and its managing Weblogic Admin Server must be restarted after either of the configuration options.

9.7.3.1 Using frmconfighelper script for the web-tier partner application registration and configuring policy

frmconfighelper script uses the Oracle Access Manager's RREG tool to perform partner application registration and subsequently configure the policy on the OAM. All the policy configuration details are included in the Forms OAM policy configuration file $FMW_HOME/forms/provision/FormsOAMRegRequest.xml. Users need to do the following:

Download RREG.tar located on the Oracle Access Manager Server and untar under the Oracle FMW 12c $FMW_HOME directory.
Run frmconfighelper script and pass it enable_sso option.

9.7.3.2 Using Oracle Access Manager (OAM) console for doing the web-tier partner application registration and configuring policy

Users need to perform the following steps:

Configure Webgate on the web-tier instance.

Webgate 12c is installed with FMW 12c Oracle HTTP Server, but it is not configured in OHS instance and it should be configured. Users can follow the instructions in Oracle HTTP Server 12c Webgate in FMW 12c documentation or run the frmconfighelper script and pass it enable_webgate option.
Creating Webgates on the OAM console and configure the resulting policy.

Use OAM console to create a webgate 11g agent, pass in the OHS host and port information and add the following to the Protected Resource List:

/forms/frmservlet?*oamMode=true*

Edit resources in the generated policy using the OAM console and all the following the Excluded List.

/* and /.../*

Note:

When configuring Forms and Reports in the same policy also add /reports/rwservlet/* to the Protected Resource List.
Copy ObAccessClient.xml and cwallet.sso from the OAM server to the relevant OHS under the directory DOMAIN_HOME/config/fmwconfig/components/OHS/<ohs instance>/webgate/config.

Note:

For information on frmconfighelper script, see Oracle Forms Utilities and Scripts

After installing and configuring webgate access client to work with Oracle Access Manager 11g, when the user accesses Forms application for the first time with webgate as the access client, the user will see a Java exception error. As a workaround to this issue, the user must disable the HTTPOnly parameter. To achieve this, perform the following steps:

Log in to the OAM Administration Console.
Select Authentication Schemes and navigate to LDAPScheme.
Set the ssoCookie parameter value to disablehttponly.
Click Apply.

9.7.4 Oracle Forms Remote Access Descriptor Administration

Remote Access Descriptors or RADs are used by Oracle Forms to allow its runtime to connect to an Oracle Database when applications are SSO enabled.

RADs are stored in OPSS by default. RADs can be managed from the Resource Administration pages within Fusion Middleware Control.

9.7.4.1 Accessing Resource Administration

To access the Resource Administration pages, perform the following steps:

Log into Fusion Middleware Control.
Expand the sidebar by clicking on the icon near the upper left corner, next to the domain name
Expand the Forms node then click the desired Forms instance, for example "forms1".
Expand the Forms drop-down near the upper left.
Select Security, and then select either OPSS or LDAP Resource Administration, depending on whether you are using OPSS or Oracle Internet Directory (LDAP) to store RAD information.

Figure 9-9 Forms drop-down

Description of "Figure 9-9 Forms drop-down"
On the Resource Administration page you can Add, Edit, or Delete resources.

Figure 9-10 Resources page

Description of "Figure 9-10 Resources page"

9.7.4.2 Resource Migration Assistant

The Resource Migration Assistant page allows for the migration of Oracle Forms RADs stored in Oracle Internet Directory (OID) to be moved to Oracle Platform Security Services (OPSS). This utility is intended for the purpose of migration from OID to OPPS only.

To access the Resource Migration Assistant page, perform the following steps:

Log into Fusion Middleware Control.
Expand the sidebar by clicking on the icon near the upper left corner, next to the domain name
Expand the Forms node then click the desired Forms instance, for example "forms1".
Expand the Forms drop-down near the upper left.
Select Security then select Resource Migration.
The Resource Migration page will be displayed. You will be required to enter information about the Oracle Internet Directory (OID) server to be accessed for the migration process. This selection can be changed after accessing the page by clicking on the Connect OID button.

Figure 9-11 Resource Migration Assistant

Description of "Figure 9-11 Resource Migration Assistant"
Once on the Resource Migration page, the table will display all the resources found in the OID selected. Select the entries in the table that should be migrated to OPSS then click Migrate. The status of the transfer will be displayed in a popup dialog.

Figure 9-12 Resource Migration Assistant page

Description of "Figure 9-12 Resource Migration Assistant page"