The ability to control user access to Web content and to protect your site against people breaking into your system is critical. This chapter describes the architecture and configuration of security for Oracle Forms Services:
See Also:
For additional information about security, refer to the following documents:
Oracle Fusion Middleware Security Overview provides an overview of Oracle Fusion Middleware security and its core functionality.
Oracle Fusion Middleware Getting Started with Oracle Identity Management provides guidance for administrators of the Oracle security infrastructure.
Single Sign-on in Oracle Forms Services is available through mod_osso or webgate, Oracle modules for the Oracle HTTP Server. mod_osso authenticates a user against Oracle Single Sign-On Server or Oracle Access Manager (OAM) 11g, which in turn uses Oracle Internet Directory as a user repository, before further passing the Forms application request to the Forms servlet. The webgate access client authenticates a user against Oracle Access Manager (OAM) 11g.
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, mod_osso or webgate and the Forms servlet are now integrated in a Web-based authentication server environment.
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 Server 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 Server. 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 Server credentials; however, all users share a common database connect (information) for the application defined by a default RAD entry.
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.
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.
When you enable Single Sign-On for your Forms applications, you can secure your Forms applications with these features:
The dynamic mod_osso directive runs Single Sign-On protected Forms applications. This directive can optionally be used to run non-protected Forms applications from the same Oracle Forms Services instance. These applications use the same configuration files and Forms servlet. Single sign-on is enabled for applications by a Single Sign-On parameter in the application definition of the formsweb.cfg configuration file.
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 funtionality to redirect to DAS pages is achieved with the single sign-on parameter ssoDynamicResourceCreate.
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.
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 Section 9.1.2, "Authentication Flow".
Oracle Forms Services has tighter integration with Oracle Internet Directory with minimal configuration. When you configure an authentication server for your Forms applications, Oracle Forms Services handles much of the configuration and interaction with Oracle Internet Directory.
With the absence of Repository API in 11g, Oracle Forms and Identity Management integration involves the registration of Forms application identity at the time of deployment when a relationship is established between Forms and the Oracle Internet Directory (OID) host. This process is known as associating with the Oracle Internet Directory. Related information such as Forms Distinguished Name (formsDN) and the password are stored in Credential Storage Framework (CSF). At run time, a JNDI connection is made to Oracle Internet Directory after extracting the required information from CSF. Oracle Forms and Identity Management integration involves the following:
Integration at bootstrap: The Forms application entity (and Distinguished Name) with a password is created in Oracle Internet Directory.
Integration at run time: Previously, the connection to Oracle Internet Directory used Repository API. In 11g, a JNDI call is used to directly connect to Oracle Internet Directory.
For more information about associating and disassociating Oracle Internet Directory, see Section 9.7, "Postinstallation Configuration."
Configuring security for Oracle Forms Services is done through Oracle Fusion Middleware Control. Online help is available for each screen. For more information, see Chapter 4, "Configuring and Managing Forms Services" and Chapter 9, "Using Forms Services with Oracle Single Sign-On".
Oracle Forms Services can be configured to create resources dynamically in Oracle Internet Directory, or have a user with no Oracle Internet Directory resource use a common resource.
For more information, see Chapter 9, "Using Forms Services with Oracle Single Sign-On".
For more detailed information about configuring and securing Oracle Forms, see the following chapters:
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---