This article describes how to configure the Okta Access Gateway to enable SSO with the Oracle Forms/Report Server 11gR2.

A standard Oracle Forms/Report server is capable of performing SSO via the Oracle OAM integration. In our scenario, the Access Gateway replaces the Oracle OAM and acts on behalf of OAM/WebGate to communicate with the Oracle Forms server via the Oracle HTTP header parameter. Once the Forms server receives the appropriate header value, it will retrieve the RAD entry from the backend LDAP server and authenticate the user with the incoming username.

Create Access Gateway Forms/Report Application

  1. Log in to the Access Gateway Admin console.

  2. Create a Header-based application and name it appropriately.

    Oracle Forms/Report Installation

  3. Enter the appropriate value for the Public Domain, Protected Web Resource, and Post Login URL.

    • Public Domain: This is the hostname where the Forms user will access the app via the internet/intranet.

    • Protected Web Resource: This is the backend Forms Server. Usually it is the OHS server and its listening port, which fronts the Forms WLS server.

    • Post Login URL: This is the URL where the Forms Applet resides. In the picture shown below, we are accessing the webgate Forms Applet.

      Make sure the WebGate Agent protecting the Forms server is disabled. Oracle Forms/Report Installation

  4. Set up the appropriate header parameter OAM_REMOTE_USER, which is expected by the Forms server.

    The value of this attribute comes from the configured IDP. In this case, we use the "firstName" column. Make sure it matches the OID uid of the user. Oracle Forms/Report Installation

  5. Click Done to complete the setup.

Disable Existing SSO OAM WebGate Agent for Forms server

A typical customer Forms/Report environment would already have the OAM protecting it via the Oracle WebGate web server. WebGate is installed on the Forms/Report server. It contains an OAM Agent that is constantly communicating to OAM for policy authorization.

In addition, all SSO Forms/Report users will have valid Resource Access Descriptor (RAD) entries in the corresponding OID/OUD. There is no additional configuration changes required to use the existing RAD via Forms Applet through the Access Gateway.

In order to use the Access Gateway to protect the Forms server, we need to disable the existing Oracle WebGate, along with its Agent.

  1. Edit the forms OHS server configuration file shown below.

  2. Comment out the include statement for WebGate .

    vi /u01/app/oracle/product/fmw11g/Oracle_OHS11gWG/instances/instance1/config/OHS/ohs1/httpd.conf
    # Comment out the include line below to disable WebGate
    #include "/u01/app/oracle/product/fmw11g/Oracle_OHS11gWG/instances/instance1/config/OHS/ohs1/webgate.conf"

Resource Adapter Descriptor

Resource Access Descriptors (RAD) are entries in Oracle Internet Directory that are defined for each user and application that 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, mod_osso or webgate and the Forms servlet are now integrated in a Web-based authentication server environment.

When we integrate the Access Gateway with an existing SSO-enabled Forms server, all the Forms users already have the RAD entries created in the backend OID. The Forms Applet will retrieve the RAD entry automatically when the user completes a SSO authentication into the service, hence the Access Gateway does not need to concern itself with the retrieval of the RAD entry from the backend OID server.

Here is a sample RAD entry for user francis.smith. If the RAD entry is missing for the test user, the Forms Applet will prompt for the DB connection string.

Use ldapadd to add the RAD entry for test users:

$/u01/app/Middleware/Oracle_IDM1/bin/ldapadd -h -p 3060 -D “cn=orcladmin” -w Password1 -f francisSmithRAD.ldif`

cat francisSmithRAD.ldif

### Sample LDIF for a RAD enabled user

### User Francis Smith ldif Sample:

dn: cn=francis.smith,cn=users,dc=okta,dc=info
uid: francis.smith
givenName: francis
cn: francis.smith
sn: smith
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: orcluser
objectClass: orcluserV2
userpassword: francis1
orclpassword: francis1

### Owner GUID ldif Sample:

dn: orclownerguid=C4811679FEAC709FE0408D0AA29C0F49, cn=Extended Properties,cn=OracleContext,dc=okta,dc=info
objectclass: top
objectclass: orclReferenceObject
orclownerguid: C4811679FEAC709FE0408D0AA29C0F49

dn: cn=Resource Access Descriptor, orclownerguid=C4811679FEAC709FE0408D0AA29C0F49, cn=Extended Properties,cn=OracleContext,dc=okta,dc=info
objectclass: top
objectclass: orclcontainer
objectclass: orclAuxiliaryGUID
orclownerguid: C4811679FEAC709FE0408D0AA29C0F49
cn: Resource Access Descriptor

### RAD ldif Sample:

dn: orclresourcename=fsrad+orclresourcetypename=OracleDB, cn=Resource Access Descriptor,  orclownerGUID=C4811679FEAC709FE0408D0AA29C0F49, cn=Extended Properties , cn=oraclecontext, dc=okta,dc=info
orclresourcetypename: OracleDB
orclflexattribute1: orcl112
orcluseridattribute: scott
orclownerguid: C4811679FEAC709FE0408D0AA29C0F49
orclusermodifiable: true
orclpasswordattribute: tiger
orclresourcename: fsrad
objectclass: top
objectclass: orclresourcedescriptor