9 Using Forms Services with Oracle Fusion Middleware Single Sign-On

This chapter contains the following sections:

Section 9.1, "Overview"
Section 9.2, "Available Features with Oracle Single Sign-On, Oracle Internet Directory and Forms"
Section 9.3, "Oracle Single Sign-On Components Used By Oracle Forms"
Section 9.4, "Enabling Oracle Single Sign-On for an Application"
Section 9.5, "Integrating Oracle Forms and Reports"
Section 9.6, "Enabling and Configuring Proxy Users"
Section 9.7, "Configuring Oracle Internet Directory"

9.1 Overview

Oracle Forms Services applications can run in a Single Sign-on environment using Oracle Single Sign-On Server and Oracle Internet Directory to store user name and password information. Oracle Single Sign-On is designed to work in Web environments where multiple Web-based applications are accessible from a Browser. Without Oracle Single Sign-On, each user must maintain a separate identity and password for each application they access. Maintaining multiple accounts and passwords for each user is unsecured and expensive.

Oracle Single Sign-On Server enables 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 Oracle Single Sign-On Server only for obtaining database connection authentication. Once this connection is made, interaction with Oracle Single Sign-On Server no longer occurs. Exiting a Forms application does not perform an Oracle Single Sign-On Server logout. Conversely, logging out of an Oracle Single Sign-On Server session does not terminate an active Forms session. The database session exists until the Forms Runtime (for example, frmweb.exe) on the server terminates, usually by explicitly exiting the form.

Oracle Single Sign-On Server can be used to authenticate other applications that are not Oracle products, for example, custom-built Java EE applications.

Oracle Forms applications integrate into a company's Oracle Single Sign-On Server architecture based on Oracle Single Sign-On Server and the Oracle Internet Directory. 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:

Refer to the Section 3.4.2, "Forms Single Sign-On on Mozilla 3.x" for more information on browser support for Forms and Single Sign-On.

9.1.1 Authentication Flow

Figure 9-1 describes the authentication flow of Oracle Single Sign-On Server support in Oracle Forms the first time the user requests an application URL that is protected by Oracle Single Sign-On Server:

Figure 9-1 Authentication Flow for First Time Client Request

Authentication flow when client makes initial request.

In the upper left of the image, the user requests a Forms URL similar to http(s)://<hostname>:<port>/forms/frmservlet?config= <application>&...
The Forms servlet redirects the user to the Oracle Single Sign-On Server server and its login page, indicated on the bottom left of the image.
The user provides user name and password through the login form.
The password is verified through Oracle Internet Directory (LDAP Server), shown at the center of the image.
The user is redirected to the URL with sso_userid information, indicated in the upper right of the image.
The Forms servlet retrieves the database credentials from Oracle Internet Directory.
The Forms servlet sets the user ID parameter in the Runform session and permits the applet to connect to the Forms listener servlet.
The Forms servlet starts the Forms server.

Figure 9-2 describes the authentication flow of Oracle Single Sign-On Server support in Oracle Forms Services when a user, authenticated through another partner application, requests an application that is protected by Oracle Single Sign-On Server.

Figure 9-2 Authentication Flow for Subsequent Client Requests

The user requests the Forms URL, as shown in the upper left side of the image.
The Forms servlet redirects the user to the Oracle Single Sign-On Server server and its login page, indicated on the bottom left of the image.
The user is redirected to the URL with the sso_userid information.
The Forms servlet retrieves the database credentials from Oracle Internet Directory, as shown in the center of the image.
The Forms servlet sets the user ID parameter in the Runform session and the applet connects to the Forms listener servlet.
The Forms servlet starts the Forms server, shown on the bottom right of the image.

9.2 Available Features with Oracle Single Sign-On, Oracle Internet Directory and Forms

The following features and enhancements are available with this release of Oracle Forms Services:

Section 9.2.1, "Dynamic Resource Creation When A Resource Is Not Found In Oracle Internet Directory"
Section 9.2.2, "Support for Dynamic Directives With Forms and Oracle Single Sign-On"
Section 9.2.3, "Support for Database Password Expiration for Forms Running with Oracle Single Sign-On"

9.2.1 Dynamic Resource Creation When A Resource Is Not Found In Oracle Internet Directory

In Single-Sign On mode, when a user tries to connect to a database using Forms, the user is authenticated by mod_osso in combination with the Oracle Single Sign-On Server and Oracle Internet Directory. Once the user is authenticated, the user is directed to the Forms servlet which takes the user's request information containing the Oracle Single Sign-On Server user name. The user name and the application name build a unique pair that identifies the user's resource information for this application in Oracle Internet Directory.

When an authenticated Forms user has neither the resource for a particular application that is being requested nor a default resource in Oracle Internet Directory, then the user is redirected to a Oracle Internet Directory/DAS page to dynamically create them. After creating the resource, the user is redirected back to the original Forms request URL.

The way Forms Services handles the missing resource information can be customized by the application or 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.2.2 Support for Dynamic Directives With Forms and Oracle Single Sign-On

Enforcing Oracle Single Sign-On Server in Forms is done within the formsweb.cfg file. The Oracle Single Sign-On Server parameter, ssoMode, when set to TRUE, indicates that the application requires authentication with an Oracle Single Sign-On Server.

This parameter allows a Forms Services instance to handle both application types, ones protected by database password and ones protected by Oracle Single Sign-On Server. Because Oracle Single Sign-On Server is configured in the formsweb.cfg file, Enterprise Manager Fusion Middleware Control can be used to manage this aspect of authentication.

9.2.3 Support fo r Database Password Expiration for Forms Running with Oracle Single Sign-On

In previous releases of Oracle Forms, changing a database password would be successful, but the changes (including expirations) would not propagate to Oracle Internet Directory.

In Oracle Forms Services 11g, if the database password has expired and the Forms Services application, running in Oracle Single Sign-On Server mode, is used to renew it, the new password entered by the user is used to update the Resource Access Descriptor (RAD) in Oracle Internet Directory for this application. This feature ensures that authenticating a Forms user via Oracle Single Sign-On 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 Oracle Internet Directory.

9.3 Oracle Single Sign-On Components Used By Oracle Forms

The following software components in Oracle Fusion Middleware are involved when running Forms applications in Oracle Single Sign-On Server mode:

Oracle Single Sign-On Server - an authentication Service in Oracle Fusion Middleware that uses Oracle Internet Directory to store user names and passwords
mod_osso - The HTTP module mod_osso simplifies the authentication process by serving as the sole partner application to the Oracle Single Sign-On Server, rendering authentication transparent for applications. Oracle Forms Services and Oracle Reports Services use mod_osso to register as partner applications with the Oracle Single Sign-On Server.
Oracle Internet Directory - A LDAP v3 compliant directory server that stores user login information. An LDAP server is a special database that is optimized for read access.
Forms servlet - The Oracle Forms Services component that accepts the initial user request to start a Forms application. The Forms servlet detects if an application requires Oracle Single Sign-On Server, directs the request to the Oracle Single Sign-On Server and accesses the Oracle Internet Directory to obtain the database connect information.
formsweb.cfg - The Forms configuration file that contains the parameters to enable a Forms application for Oracle Single Sign-On Server. The formsweb.cfg file is located in the $<WLS_FORMS Managed Server Directory>/stage/formsapp/11.1.1/formsapp/config/ directory.

9.4 Enabling Oracle Single Sign-On for an Application

Oracle Forms applications are configured using a central configuration file, the formsweb.cfg file in the $<WLS_FORMS Managed Server Directory>/stage/formsapp/11.1.1/formsapp/config/ directory. The recommended method of managing formsweb.cfg file is using Fusion Middleware Control.

Oracle Single Sign-On Server and error handling are defined by the following parameters in the formsweb.cfg file:

ssoMode [true|false]
ssoProxyConnect [yes|no]
ssoDynamicResourceCreate [true|false]
ssoErrorUrl [String URL]
ssoCancelUrl [String URL]

These Oracle Forms parameters in the formsweb.cfg file are set in the "User Parameter" section, which make them the default behavior for all Forms applications run by the server. These parameters can also be set in a "Named Configuration", which make the settings valid for a particular application only. An Oracle Single Sign-On Server definition overrides the same definition set in the User Parameter section.

To enable Oracle 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 the row containing ssoMode.
In the Value field, enter true.
Click Apply to update the formsweb.cfg file.

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

To disable Oracle 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 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 Forms Services application to connect to Oracle Single Sign-On Server. By default, Oracle Forms applications are not configured to run in Oracle Single Sign-On Server 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 which allows all applications to run in Oracle Single Sign-On Server mode by this Forms Services instance
By setting the ssoMode parameter in a named configuration of an Oracle Forms application which enables or disables Oracle Single Sign-On Server 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 ssoMode 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 Oracle Single Sign-On Server mode by this 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 Oracle Internet Directory to run the application if this resource entry does not exist. The Web page used is a standard form provided by the Oracle Delegated Administration Services. This Web page cannot be customized as it is not owned by Oracle Forms.

Allowing dynamic resource creation simplifies Oracle Internet Directory 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.

Note that configuring an application as Oracle Single Sign-On Server enabled 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 (and potentially raising issues with Oracle Internet Directory), these parameters allow administrators to control Oracle Internet Directory 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 Section 4.2.4, "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 only has effect 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 Oracle Single Sign-On Server authentication information in a Forms application, the GET_APPLICATION_PROPERTY() Built-in can be used to retrieve the following Oracle Single Sign-On Server login information: Oracle Single Sign-On Server 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).

Note:

config can be obtained even in non-SSO mode.

9.5 Integrating Oracle Forms and Reports

Oracle Reports is installed with Oracle Single Sign-On 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 a Oracle Single Sign-On Server protected Oracle Forms application, the authenticated user's Oracle Single Sign-On Server identity is implicitly passed to the Reports Server with each call to RUN_REPORT_OBJECT built-in. The Oracle Single Sign-On Server identity is used to authenticate the user to the Reports Server for further authorization checking, if required.

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

For more information on enabling single sign-on in Forms, see Section 9.4, "Enabling Oracle Single Sign-On for an Application".

For more information on configuring single sign-on in Reports, refer to the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

For more information about integrating Oracle Forms and Oracle Reports, see the white paper Integrating Oracle Forms 11g and Oracle Reports 11g at Oracle Technology Network http://www.oracle.com/technology/products/forms/.

9.5.1 Forms and Reports Integration in non-SSO mode

Prior to 11g Release 1 (11.1.1), Oracle Reports generated sequential job IDs, making it easy to predict the job ID. This meant that unauthorized or malicious users could potentially view the job output using GETJOBID through rwservlet to obtain job output that belongs to another user. In 11g, Oracle Reports generates random and non-sequential job IDs to make it impossible to predict the job ID for a particular job. Only the user who runs a report from Oracle Forms Services is able to see its output. Other users should not be able to see the report output as job IDs are random non-sequential numbers.

For a non-secure Reports Server, the user ID and password for administrators can be set in the identifier element of the Reports Server configuration file.

For more information on configuring the access levels for the users, refer to the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

9.5.2 Using Multiple Reports Server Clusters in Oracle Forms Services

If your Oracle Forms Services application from a prior release uses multiple Reports Server cluster names, you can map each of those cluster names to a different Reports Server. In Oracle Reports 11g Release 1 (11.1.1), Reports Server clustering was deprecated. An Oracle Forms Services application from prior releases that includes a Reports Server cluster name will fail to bind to the Reports Server cluster it references.

To resolve this issue, the reports_servermap element maps a cluster name to a Reports Server name. This avoids the necessity to change the cluster name in all Oracle Forms Services applications.

An Oracle Forms Services application can call Oracle Reports in the following ways:

Using RUN_REPORT_OBJECT: If the call specifies a Reports Server cluster name instead of a Reports Server name, the reports_servermap environment variable must be set in the Oracle Forms Services default.env file. If your Oracle Forms Services application uses multiple Reports Server cluster names, you can map each of those cluster names to a different Reports Server using reports_servermap, as follows:

<reports_servermap>

cluster1:repserver1;cluster2:repserver2;cluster3:repserver3

</reports_servermap>

For example, if your Oracle Forms Services application includes 3 clusters with names dev_cluster, prd_cluster, and qa_cluster in 10.1.2, you can map these cluster names to respective server names in later releases, as follows:

<reports_servermap>

dev_cluster:dev_server;prd_cluster:prd_server;qa_cluster:qa_server

</reports_servermap>
Using WEB.SHOW_DOCUMENT: In this case, the request is submitted to rwservlet. If the call specifies a Reports Server cluster name instead of a Reports Server name, the reports_servermap element must be set in the rwservlet.properties file. For example:

<reports_servermap>

cluster:repserver

For more information, see the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

9.5.3 Integrating Forms and Reports Installed in Different Instances

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. For more information, see Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services.

9.6 Enabling and Configuring Proxy Users

This section contains the following:

Section 9.6.1, "Proxy User Overview"
Section 9.6.2, "Authentication Flow"
Section 9.6.3, "Enabling Proxy User Connections"
Section 9.6.4, "Proxy User Configuration Example"
Section 9.6.5, "Changes in Forms Built-ins"
Section 9.6.6, "Reports Integration with Proxy Users"

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.

9.6.2 Authentication Flow

Figure 9-3 describes the authentication flow for a Forms proxy user.

Figure 9-3 Proxy User Authentication Flow

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.
The database accepts the create session action for the proxy user and uses the real username in audits and access control.
The proxy user only has "create session" privileges so a user has to be authenticated.
The Oracle Internet Directory user does not have create session privileges and cannot log on to the database without knowing the proxy user name and password.

9.6.3 Enabling Proxy User Connections

To use a proxy user in Forms you first need to create a proxy user. In this example, the proxy user is called midtier:

SQL> create user midtier 
identified by midtierPW;
SQL> grant create session to midtier;

So far, there is nothing special with this user other than that it has very limited privileges. The user cannot do anything in the database since the user cannot connect.

Next, create the application user:

SQL> create user scott 
identified by tiger;

To make it possible to connect through the midtier user you need to alter the application user:

SQL> alter user scott
grant connect through midtier 
with role connect;

The application user scott can now connect through the midtier account by making the midtier account a proxy 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. 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.

9.6.4 Proxy User Configuration Example

The application user's password is never 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[scott]/midtierPW@databaseTnsName

In this example, issuing the select statement select user from dual in the database returns scott and not midtier.

This example 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.

9.6.4.1 Configuration in formsweb.cfg

Make sure you are using single sign-on by setting ssoMode=true. Then set ssoProxyConnect=yes.

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

SQL> connect RADUsername[scott]/RADPassword@databaseTnsName

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.

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 more information about Reports configuration files, see the Oracle Fusion Middleware Publishing Reports to the Web with Oracle Reports Services

9.7 Configuring Oracle Internet Directory

The users connecting through a Forms application as proxy users must also be defined in Oracle Single Sign-On and Oracle Internet Directory. Oracle Forms authenticates the user via Oracle Single Sign-On (using Oracle Single Sign-On with Forms is a requirement when employing 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.

For more information on Oracle Forms and Identity Management integration, see Section 11.1.4, "Leveraging Oracle Identity Management Infrastructure."

Note:

When you change the Oracle Web Cache port using Enterprise Manager, regenerate the osso.conf and copy the generated osso.conf file to $ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/moduleconf directory. Restart the Oracle HTTP Server and Oracle Web Cache for the changes to take effect.

To access the Associate/Disassociate OID page:

Start Enterprise Manager.
Navigate to the Forms Home page.
From the Forms menu, select Associate/Disassociate OID.

The Associate/Disassociate OID page is displayed.

Figure 9-4 Associate/Disassociate OID

Description of "Figure 9-4 Associate/Disassociate OID"

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/Disasociate OID page, select the Forms application. Click Associate.

The Associate dialog appears.
Enter the Oracle Internet Directory Host details as described in Table 9-1, "Oracle Internet Directory Host Details".

Click Associate.

The Associate/Disasociate OID page reappears.

Table 9-1 Oracle Internet Directory Host Details

Parameter	Description
OID Host	Select the Oracle Internet Directory Host from the list or select Add OID host to add new Host details.
New OID host	Host name of the LDAP directory server. This field is enabled if you have selected to add new Oracle Internet Directory Host.
New OID Port	Port number on which LDAP is listening. This field is enabled if you have selected to add new Oracle Internet Directory Host.
Username	Oracle Administrator username
Password	Oracle Administrator password

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 Disassociate OID Host from a Forms Application

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

A confirmation box appears.
Click No.

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 Table 9-1, "Oracle Internet Directory Host Details".

On the Oracle Single Sign-On Server, run the ssoreg.sh script from $ORACLE_HOME/sso/bin.

ORACLE_HOME/sso/bin/ssoreg.sh 
-oracle_home_path <ORACLE_HOME>
-site_name www.example.com
-config_mod_osso TRUE
-mod_osso_url http://www.example.com:7777
-config_file osso.conf

On Windows, run the ssoreg.bat file.

Copy the generated osso.conf file to $ORACLE_INSTANCE/config/OHS/<OHS_INSTANCE>/. For more information, see the Oracle Application Server Single Sign-On Administrator's Guide on OTN.
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.

9 Using Forms Services with Oracle Fusion Middleware Single Sign-On

9.1 Overview

9.1.1 Authentication Flow

9.2 Available Features with Oracle Single Sign-On, Oracle Internet Directory and Forms

9.2.1 Dynamic Resource Creation When A Resource Is Not Found In Oracle Internet Directory

9.2.2 Support for Dynamic Directives With Forms and Oracle Single Sign-On

9.2.3 Support for Database Password Expiration for Forms Running with Oracle Single Sign-On

9.3 Oracle Single Sign-On Components Used By Oracle Forms

9.4 Enabling Oracle Single Sign-On for an Application

9.4.1 ssoMode

9.4.2 ssoProxyConnect

9.4.3 ssoDynamicResourceCreate

9.4.4 ssoErrorURL

9.4.5 ssoCancelUrl

9.4.6 Accessing Single Sign-on Information From Forms

9.5 Integrating Oracle Forms and Reports

9.5.1 Forms and Reports Integration in non-SSO mode

9.5.2 Using Multiple Reports Server Clusters in Oracle Forms Services

9.5.3 Integrating Forms and Reports Installed in Different Instances

9.6 Enabling and Configuring Proxy Users

9.6.1 Proxy User Overview

9.6.2 Authentication Flow

9.6.3 Enabling Proxy User Connections

9.6.4 Proxy User Configuration Example

9.6.4.1 Configuration in formsweb.cfg

9.6.5 Changes in Forms Built-ins

9.6.6 Reports Integration with Proxy Users

9.7 Configuring Oracle Internet Directory

9.2.3 Support fo r Database Password Expiration for Forms Running with Oracle Single Sign-On