A Forms installation holds database passwords, runs code on a server, and sends data across the network, so its security is more than a login screen. It is a set of choices: how users are identified, where secrets are kept, and which settings close the doors an attacker would try first.
This guide covers securing Oracle Forms 14.1.2: the three ways a Forms application learns who its user is, single sign-on with Oracle Access Manager, credentials on the server, and a checklist of settings that close common holes.
Three Ways to Know the User
| Approach | How it works | Trade-off |
|---|---|---|
| Database logon | Each user is a database user; the section's userid is empty, and Forms shows its logon dialog. Database roles decide what each user may do. | Simple, but every user needs a database account and a password to type. |
| Application logon | The form connects with one database account, and a login form checks the user against the application's own table. | The application carries the whole burden of security, and the shared password lives in the configuration. |
| Single sign-on | The user signs on once, to Oracle Access Manager, for every application of the organization; Forms connects to the database for them. | The most secure and convenient, but it needs Oracle HTTP Server, WebGate, and Access Manager. |
Database roles and application roles are compared in how to secure menus with roles in Oracle Forms.
Single Sign-On
Single sign-on puts Oracle HTTP Server with WebGate in front of the Forms servers, and Oracle Access Manager behind WebGate: a request for a protected Forms URL is sent to Access Manager to sign on first.
Forms then knows the user's single sign-on name, and needs the user's database connection. It keeps it in the Forms Identity Store, Oracle Platform Security Services by default or Oracle Internet Directory, as a resource access descriptor for each user and application.
- The first time a user runs the application, Forms asks for the database user and password and stores them (ssoDynamicResourceCreate).
- A password that expires is renewed through Forms, which updates the store.
Enable It in formsweb.cfg
A section enables single sign-on with ssoMode=webgate. ssoProxyConnect=yes connects as a proxy user instead: one account of the application, acting for the signed-on user, who needs no password of their own in the database.
In the form, GET_APPLICATION_PROPERTY(SSO_USERID) returns the signed-on user, and the Logout system event tells the form that the single sign-on session ended. Reports and Forms share the sign-on, which lets RUN_REPORT_OBJECT run secured reports, as described in how to run Oracle Reports from a form.
Oracle's documentation, Working with Oracle Forms, describes the installation in detail: Oracle HTTP Server, WebGate, and registering Forms as a partner application with the frmconfighelper script.
Keep Credentials on the Server
Passwords and tokens the Forms server itself uses, such as those for REST services, belong in the domain's credential store, part of Oracle Platform Security Services. In Fusion Middleware Control, WebLogic Domain, Security, Credentials lists its credential maps. Forms reads REST credentials from the map FormsREST, each under a key, the Credential ID used by the REST Package Designer.
WLST creates the same.
Create a REST credential with WLST:
createCred(map='FormsREST', key='CW_CLAIMS', user='bearer', password='...',
desc='CareWell claims service')A development domain without a repository has no management interface for the store, as explained in how to call REST services from Oracle Forms.
Close the Common Holes
| Risk | Setting |
|---|---|
| A password in the configuration | Encrypted userid in Fusion Middleware Control; better, single sign-on or a proxy user. |
| Users choosing the form, the account, or the configuration in the URL | restrictedURLparams with userid, form, config, and otherparams. |
| Forms started from any directory | FORMS_MODULE_PATH. |
| Commands run on the server by HOST | FORMS_BLOCK_HOST_CMD. |
| Code reading the user's password | FORMS_HIDE_PASSWORD=TRUE. |
| Users writing their own query conditions | FORMS_RESTRICT_ENTER_QUERY. |
| Traffic read on the network | HTTPS: an SSL port in WebLogic, or Oracle HTTP Server with TLS in front. |
| Client code changed on the way | Signed JAR files. |
| Files transferred anywhere | webutil.cfg limits. |
| Reports run by anyone | Reports roles and single sign-on. |
| Too much access in the database | Database roles for each kind of user, and an application account with only the privileges it needs. |
The URL and environment settings are explained in how to configure formsweb.cfg and how to set the Oracle Forms runtime environment, and WebUtil's limits in how to use WebUtil in Oracle Forms.
Conclusion
An Oracle Forms application identifies users by database logon, by its own login form, or best of all by single sign-on with Oracle Access Manager, where the Forms Identity Store holds each user's database connection or a proxy user acts for them. Keep secrets in the domain's credential store and out of the configuration, restrict URL parameters, and use the FORMS_ environment switches, HTTPS, signed JARs, WebUtil limits, and least-privilege database accounts to close the common holes.
