6 Using Forms Services with Oracle Application Server Single Sign-On and OID

6.1.1 Dynamic Resource Creation When A Resource Is Not Found In OID

A user connects to Forms and is authenticated by mod_osso in combination with the SSO Server and OID. Once the user is authenticated, the user is directed to the Forms Servlet which takes the user's request information containing the SSO user name. The user name and the application name build a unique pair that identifies the user's resource information for this application in OID.

When an authenticated Forms user has no resource information for the particular application that is being requested in OID, then the user receives a Forms error message saying that no resource is available for this application, by default.

The way Forms Services handles the missing resource information is customizable by the application or Forms Services administrator. The following options are available:

• Display Forms error message (default)

• Redirect the user to a defined URL

• Display the Forms logon screen

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

6.1.2 Support for Default Preferences in OID to Define Forms Resources

In previous releases, Forms uses resources added to each individual user account using the Oracle Delegated Administration Services (DAS). This implementation means that even if users share a common resource, it needs to be implemented for each user, no matter if there are 10 of them or 10,000.

In this Forms release, Forms and application administrators can define common used resources as default resources using the OID preferences. An administrator creates a resource once and all user accounts automatically inherit this resource to be used within Forms.

6.1.3 Support for Dynamic Directives With Forms SSO

Enforcing single sign-on in Forms is now done within the formsweb.cfg file. There is now a new SSO parameter, mod_sso, to indicate when a custom application requires SSO authentication.

This parameter allows a Forms Services instance to handle both application types, public and single sign-on protected Forms. Because single sign-on is configured in the formsweb.cfg file, Enterprise Manager Application Server Control can read and write the single sign-on parameter.

For more information, see "ssoDynamicResourceCreate".

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

In previous releases of Oracle Forms, password changes between Oracle Forms and an Oracle database would be successful, but these changes (including expirations) would not propagate to Oracle Internet Directory (OID).

Now in Oracle Application Server Forms Services, if the database password has expired and the Oracle9iAS Forms Services application, running in single sign-on mode, is used to renew it, then the new password entered by the user is used to update the Resource Access Descriptor (RAD) in OID for this application. This feature ensures that single sign-on with Forms continues working even when a database password was changed. However, if password changes are made in SQL*PLUS, and not in Forms, then the database connect string is not updated in OID.

6.3.1 ssoMode

The ssoMode parameter enables an Oracle Application Server Forms Services application for single sign-on. 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. Setting ssoMode as a system parameter with a value of true allows all applications to run in single sign-on mode by this Forms Services instance. Setting the ssoMode parameter in a named configuration of an Oracle Forms application enables or disables single sign-on only for this particular application:

[myApp]
form=myFmx
ssoMode=true

1. Start the Enterprise Manager Application Server Control.

2. Select Forms.

3. Select the Configuration tab.

4. Select the radio button next to the configuration section for your application and click Edit.

5. In the Name field, enter ssoMode.

6. In the Value field, enter true.

7. Click Add New Parameter.

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

1. Start the Enterprise Manager Application Server Control.

2. Select Forms.

3. Select the Configuration tab.

4. Select the radio button next to the configuration section for your application and click Edit.

5. Select the radio button next to the ssoMode parameter.

6. In the Value column, enter false.

7. Click Apply.

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

   Optionally, when you set ssoMode to false, you can redirect users to an informational page by specifying a URL in the ssoErrorUrl parameter.

6.3.2 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 (OID) to run the application if this resource entry does not exist. The Web page that displays is a standard form provided by the Oracle Delegated Administration Services (DAS). This Web page is not customizable as it is not owned by Oracle Forms.

Allowing dynamic resource creation simplifies OID 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 single sign-on enabled with the value of the ssoDynamicResourceCreate parameter set to false, while not specifying a value for the ssoErrorURL, will cause 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 OID), these parameters allow administrators to control OID 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'll need to set these parameters:

[myApp]
form=myFmx
ssoMode=true
ssoDynamicResourceCreate=false

For information about setting these parameters through Enterprise Manager Application Server Control, see Chapter 4, "Managing Parameters".

6.3.3 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 as a system parameter 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://myServ.com:7779/servlet/handleCustomRADcreation.jsp
…

6.3.4 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 he presses the cancel button in the HTML form that is used to dynamically create the RAD entry for the requested application.

6.3.5 Accessing Single Sign-on Information From Forms

Optionally, if you need to work with single sign-on authentication information in a Forms application, the GET_APPLICATION_PROPERTY() built-in can be used to retrieve the following single sign-on login information: Oracle Application Server 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') ;