Security Overview

Single Sign-On

Single Sign-on in Oracle Forms Services is available through webgate, Oracle modules for the Oracle HTTP Server. The webgate access client authenticates a user against Oracle Access Manager (OAM).

Review Using Forms Services with Oracle Access Manager for more informtaion.

Forms applications expect a database connect string to be passed along with the application request, otherwise a logon dialog is shown. To retrieve the database connect information in the Single Sign-On environment, the Forms servlet queries Oracle Internet Directory for the value of the combined unique key that is constructed from the user's single sign-on server name, the authenticated user name, and the name of the application that the user is requesting to start.

Resource Access Descriptors (RAD) are entries in Oracle Internet Directory that are defined for each user and application which contain the required database connect information. The Forms servlet reads the database connect information from the RAD and passes it along with the command line that starts the Forms Web application. Although the Forms authentication is still database-centric, or webgate and the Forms servlet are now integrated in a Web-based authentication server environment.

For more information, see:

Classes of Users and Their Privileges

Historically, Forms applications use the database to authenticate application users. To use Oracle Forms Services with Single Sign-On (SSO), the user account and its connect information must be available in Oracle Internet Directory. Oracle Internet Directory provides several ways of provisioning user data, using PL/SQL, Java or the Oracle Delegated Administration Services. Oracle Delegated Administration Services is a Web-based user interface for Oracle Single Sign-On users and delegated administrators to administer self-service data in Oracle Internet Directory for which they are authorized.

Once a user account is created in Oracle Internet Directory, the Resource Access Descriptors (RAD) entries can be created dynamically the first time that a user requests a Forms application, assuming the user knows about the database connect information required for this application.

Another option is to use the RAD entries that can be created using Oracle Delegated Administration Services. The default RAD entries are accessible for all users that are authenticated through Oracle Single Sign-On. Use the default RAD if all users share the same database connect information when running a particular Forms application on the Web. This way, users are authenticated individually by their Oracle Single Sign-On credentials; however, all users share a common database connect (information) for the application defined by a default RAD entry.

Default Single Sign-On Behavior for User Accounts

By default, the authentication server is enabled and no proxy user is involved. Oracle Forms users need to authenticate with an authentication server, retrieve Resource Access Descriptors from the identity store (which is usually Oracle Internet Directory) and use these credentials to connect to the database.

Users Using Database Proxy Functionality

There is a new Single Sign-On parameter, ssoProxyConnect. Setting this to true allows users to connect as proxy users. The user is then required to authenticate with an authentication server; a Resource Access Descriptor is configured which holds the proxy user's username and password. There is additional database configuration that needs to be implemented by the database administrator to allow for proxy connections.

Resources that are Protected

When you enable Single Sign-On for your Forms applications, you can secure your Forms applications with these features:

Dynamic Resource Creation in Oracle Internet Directory: In some previous releases of Oracle Forms Services, if no resource access descriptor (RAD) definition was found for a specific application and user, an error message was displayed which locked out the user from running that Forms application, despite having authentication to do so. In this release of Oracle Forms Services, you can now configure Oracle Forms Services to allow users to create the RAD for this application on the fly if it does not exist. The functionality to redirect to the appropriate creation pages is achieved with the single sign-on parameter ssoDynamicResourceCreate.
Database Password Expiration when Using Single Sign-On: In some previous releases of Oracle Forms Services, the RAD information in Oracle Internet Directory was not updated if the database password had expired, and users then renewed them when connecting to a Forms application. In this release, Oracle Forms Services automatically updates the RAD information in Oracle Internet Directory whenever a database password is updated through Forms. There is no extra configuration necessary to enable this feature in Oracle Forms Services.

Authentication and Access Enforcement

For detailed information about the authentication flow in Single Sign-On support in Oracle Forms Services, such as when the first time the user requests an Oracle Forms Services URL, or from a partner application, see Authentication Flow.

Security Configuration

Configuring security for Oracle Forms Services is done through Oracle Fusion Middleware Control.

Online Help is provided for the Oracle Fusion Middleware Control screens. See Configuring and Managing Forms Services and Using Forms Services with Oracle Access Manager.

Configuring Oracle Identity Management Options for Oracle Forms:
- Oracle Forms Services can be configured to create resources dynamically in Oracle Platform Security Services or Oracle Internet Directory, see Using Forms Services with Oracle Access Manager
Configuring Oracle Forms Options for Oracle Fusion Middleware Security Framework, see:

Securing RADs

To increase the security of RADs and prevent them from being viewable by the OID administrator, perform the following steps:

Copy the contents enclosed by ---aci-change.ldif--- into the file aci-change.ldif

---aci-change.ldif---
dn: cn=Extended Properties,%s_OracleContextDN%
changetype: modify
delete: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute) by
guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
-
add: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute)
DenyGroupOverride by guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
---aci-change.ldif---

Note:

In aci-change.ldif, the line beginning with orclaci: access to attr= is a single line ending with by * (none) and should not have any line breaks in the middle.

In the LDIF file, replace %s_OracleContextDN% with the distinguished name (DN) of the realm-specific Oracle Context.

For example, if the DN in the deployment is dc=acme,dc=com, then the realm-specific Oracle Context is cn=OracleContext,dc=acme,dc=com.
Execute the following command on the OID tier:

ldapmodify -p <port> -h <host> -D cn=orcladmin -q -v -f aci-change.ldif
When this command is run, it will prompt for the cn=orcladmin password since the password is not included as a command-line parameter.

To undo these changes, issue the same command (subject to the notes as above), but using the following contents in the .ldif file:

---aci-revert.ldif---
dn: cn=Extended Properties,%s_OracleContextDN%
changetype: modify
delete: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute)
DenyGroupOverride by guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
-
add: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute) by
guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
---aci-revert.ldif---

Managing URL Security for Applications

Oracle Forms applications are web-deployed solutions that users access using a URL. Oracle Forms architecture allows Forms developers two ways to choose and configure how a Forms application runs. One option is to set the parameter and the value in the URL. The second option is to set the parameter and its value(s) in the Web Configuration (formsweb.cfg).

The parameter that is set in the Web Configuration can be overridden by the parameter set in the URL. A Forms administrator can override this default behavior, and give the Forms administrator full control over what parameter can be used in the URL.

Here are two scenarios to consider when deciding which parameters to allow or not allow in a URL. The first scenario is when an administrator just wants to restrict the usage of the USERID parameter in the URL that forces the end-user to always log in using the default login window. The second scenario is when an administrator disables all parameters except a few, such as CONFIG=MyApp in a URL.

The parameter restrictedURLparams allows flexibility for the Forms administrator to consider any URL-accessible parameter in the formsweb.cfg file as restricted to a user. An administrator can specify this parameter in a named configuration section to override the one specified in the default configuration section. The restrictedURLparams parameter itself cannot be set in the URL.

By design, command line arguments passed in a URL always override similar definitions in the formsweb.cfg.

In this example, the userid is defined as user1/user1pwd and debug is set to false. An application that is configured to connect to the database as user1/user1pwd can connect as a different user with the userid parameter added as a URL parameter. To prevent it, define the userid parameter in the restrictedURLparams parameter.

Figure -43 Defining the restrictedURLparams Parameter

Description of "Figure -43 Defining the restrictedURLparams Parameter"

Similarly, an administrator can use the restrictedURLparams parameter to redirect a user to a page which lists the restricted parameters that were used. The restrictedURLparams parameter can be set to 'all' which will prevent any parameters (other than config section) from being specified in the URL.

Securing the Oracle Forms Test Form

The test form runs when you access an Oracle Forms URL but do not specify an application to run. For example, normally you call an Oracle Forms application with the following syntax:

http://<host>:<port>/forms/frmservlet?config=myApp

The Forms servlet locates [myApp] in the formsweb.cfg file and launches that application. However, when no application is specified, for example:

http://<host>:<port>/forms/frmservlet

The Forms servlet uses the settings in the default section of the formsweb.cfg file. These settings are located under [default] in the Forms Configuration file (anytime an application does not override any of these settings, the defaults are used). The default section has the following setting:

form=test.fmx

This is the test form which enables you to test your Oracle Forms Services installation and configuration. Thus if you do not specify an application, Forms launches the test.fmx file. You could change this to:

form=

And the form does not run. However, this is not optimal; the Forms servlet still sends the dynamically generated HTML file to the client, from which a curious user could obtain information. The optimally secure solution is to redirect requests to an informational HTML page that is presented to the client instead. Some parameters in the formsweb.cfg file must be changed.

Here are the parameters to change, along with their default values when you install Oracle Forms Services:

    # System parameter: default base HTML file
    baseHTML=base.htm
    # System parameter: base HTML file for use with Oracle's Java Plug-In
    baseHTMLjpi=basejpi.htm

These parameters are templates for the HTML information that are sent to the client. Create an informational HTML page and have these variables point to that instead. For example, in the $DOMAIN_HOME/config/fmwconfig/components/FORMS/instances/<Forms Instance Name>/server directory, create a simple HTML page called forbidden.html with the following content:

    <html>
      <head>
        <title>Forbidden</title>
      </head>
      <body>
       <h1>Forbidden!</h1>
        <h2>You may not access this Forms application.</h2>
      </body>
    </html>

Note:

This message page was displayed because redirecting of client information is different from the page that the Web server returns when the requested content has restricted permissions on it.

Next, modify the formsweb.cfg parameters by commenting out or modifying the original parameters:

    # System parameter: default base HTML file
    #baseHTML=base.htm
    baseHTML=forbidden.html
    # System parameter: base HTML file for use with Oracle's Java Plug-In
    #baseHTMLjpi=basejpi.htm
    baseHTMLjpi=forbidden.html
    # System parameter: base HTML file for use with Microsoft Internet Explorer
    # (when using the native JVM)

When a user enters the URL

http://<host>:<port>/forms/frmservlet

the customized Web page is presented. Of course, you can customize forbidden.html, including its contents, its filename, and its location if you make the corresponding changes to these parameters in the formsweb.cfg file. Administrators can put any information, such as warnings, errors, time stamps, IP logging, or contact information in this information Web page with minimal impact on the server configuration.

Note:

Overriding the base HTML template entries in the default section of formsweb.cfg requires that you add the same entries pointing to the original values (or some other valid HTML file) in your application-specific named configuration:

[myApp]
form=myApplication.fmx
lookandfeel=oracle
baseHTML=base.htm
baseHTMLjpi=basejpi.htm

If you do not specify these base HTML values, and when a user runs an application, the forbidden.html page is displayed because the application-specific configuration section has not overridden the default values.