This section contains security recommendations for configurations within Oracle E-Business Suite.
Follow the hardening instructions for Operating Environment Security.
When SEND_ACCESS_KEY is set to 'Y', the workflow notification email bypasses the Oracle E-Business Suite sign-on process; email notifications contain an access key. The key allows the user to access the Notification Details web page directly without authenticating. Set SEND_ACCESS_KEY to N to prevent inclusion of the key with the Notification Detail link. When set to 'N', an unauthenticated user who clicks on the notification link must sign on before accessing the Notification Details web page.
For more information, refer to the Oracle Workflow Administrator's Guide.
Verify the setting in WF_RESOURCES to see who workflow considers a workflow administrator:
select TEXT from WF_RESOURCES where NAME = 'WF_ADMIN_ROLE' ;
Ensure that the value is not set to "*" which means that everybody is a workflow administrator.
You should prevent forms users from using the enter-query feature on a production system.
In Oracle E-Business Suite Release 12, the Forms parameters are set in the configuration file:
/x/inst/apps/VIS12_dbs01/ora/10.1.2/forms/server/default.env
| Forms Environment Variable | Value |
|---|---|
FORMS_RESTRICT_ENTER_QUERY |
TRUE |
Utilize the profile options described in the following sections to secure attachments. In addition to the information below, see My Oracle Support Knowledge Document 1357849.1, Security Configuration Mechanisms in the Attachments Feature in Oracle E-Business Suite, for more details.
Profile option FND: Security File Download Time Limit (FND_GFM_ACCESS_DURATION) specifies the maximum length of time (in minutes) for accessing a Generic File Manager (GFM) file download URL. It was introduced in the July 2019 Oracle E-Business Suite Critical Patch Update (CPU).
The GFM file download URL is most commonly generated when downloading an attachment file or performing an export from an Oracle Form or Oracle Application Framework page. The default value of the profile is five minutes. The five minutes begin when the download URL is initially generated. This download URL cannot be accessed beyond the allotted five minutes. However, once the access is authenticated, the download itself can take as much time as needed.
To set the FND: Security File Download Time Limit profile option, see: "Setting Profile Options" in the Oracle E-Business Suite Setup Guide.
Profile option Upload File Size Limit (UPLOAD_FILE_SIZE_LIMIT) specifies the maximum allowable file size in KB for uploaded attachments for Oracle Application Framework and core attachments. This profile option is set with a default value of 4194304 KB (4GB) at the Site level.
For example, if you set the profile option value to 2000KB (2MB) and try to upload a file that exceeds this value, an error message similar to the following is displayed:
The file you are trying to upload has exceeded the maximum size of 2000 KB. Please upload a file of size less than 2000 KB or contact your Systems Administrator for assistance.
To address this error, set the value of the Upload File Size Limit profile option to a value that matches the size of the file to upload.
Note that for particular iRecruitment responsibilities, this profile option is more restrictive. Other levels may be set so if there are issues uploading a file due to size, the profile should be checked at all levels.
See My Oracle Support Knowledge Document 1357849.1, Security Configuration Mechanisms in the Attachments Feature in Oracle E-Business Suite.
To set the Upload File Size Limit profile option, see: "Setting Profile Options" in the Oracle E-Business Suite Setup Guide.
The File Type Validation feature was originally delivered in the Oracle E-Business Suite October 2011 Critical Patch Update (CPU) and updated in subsequent CPUs.
Before this change, users could upload any file type without restrictions. With this enhancement, users will be limited as to what file types of attachments they can upload. File types can be explicitly allowed.
With File Type Validation enabled, users receive an error message when attempting to upload a single file with a restricted file type: "This file type is not allowed. Please choose another file." This feature applies when uploading attachments through the user interface (using the Generic File Manager). Bulk file uploads by administrators will not be restricted.
File types are defined in the fnd_mime_types table. The combination of Media Type (formerly known as MIME type) and file extension uniquely identifies a file type. File types with 'N' for the column ALLOW_FILE_UPLOAD value are explicitly disallowed, as listed in the following table:
| Media (MIME) Type | File Extension | ALLOW_FILE_UPLOAD column value |
|---|---|---|
| application/jsp | jsp | N |
| application/octet-stream | wsh | N |
| application/octet-stream | jse | N |
| application/octet-stream | class | N |
| application/octet-stream | bin | N |
| application/octet-stream | exe | N |
| application/octet-stream | com | N |
| application/octet-stream | bat | N |
| application/octet-stream | cmd | N |
| application/octet-stream | wsf | N |
| application/octet-stream | vbe | N |
| application/octet-stream | vbs | N |
| application/x-javascript | js | N |
| application/x-shockwave-flash | swf | N |
| application/x-java-archive | jar | N |
The restriction on file types is also controlled by the profile option Attachment File Upload Restriction Default (FND_SECURITY_FILETYPE_RESTRICT_DFLT). This profile option determines whether a file type is allowed or not. The values for this profile option are as follows:
Yes: This is the default value on the site level. When the profile option is set to 'Yes', all file types except those with ALLOW='N' can be uploaded. That is, only file types in which the ALLOW flag is not explicitly set to 'N' in fnd_mime_types are allowed to be uploaded, as the fnd_mine_types table acts as a blocklist.
No: When the profile option is set to 'No', only file types with ALLOW='Y' can be uploaded. That is, only file types in which the ALLOW flag are explicitly set to 'Y' in fnd_mime_types are allowed to be uploaded, as the fnd_mime_types table acts as an allowlist.
NULL: If this profile option is NULL for any reason (or does not exist), then the default is to allow uploads (same as the value 'Yes').
Because a file extension can exist in the fnd_mime_types table multiple times (because the combination of mime type and file extension uniquely identifies a file type), the most restrictive value will be used.
For example, say we have the values listed in the following table:
| MIME Type | File Extension | ALLOW_FILE_UPLOAD column value |
|---|---|---|
| application/gzip | gzip | Y |
| application/x-gzip | gzip | N |
In this example, files with the extension "gzip" will be restricted from upload.
To change what file types are explicitly allowed and disallowed in the fnd_mime_types table, use the APIs as follows.
The package fnd_file_mime_types_pkg is provided to allow the administrators to insert, update, or delete from the fnd_mime_types table. Note that if you are changing a file type from disallowed to allowed, set the Allowed flag to 'Y'.
Here is the syntax of the procedures:
PROCEDURE INSERT_ROW (X_ROWID in out nocopy VARCHAR2,
X_MIME_TYPE in VARCHAR2,
X_CP_FORMAT_CODE in VARCHAR2 DEFAULT NULL,
X_CTX_FORMAT_CODE in VARCHAR2 DEFAULT 'IGNORE',
X_CREATION_DATE in DATE DEFAULT SYSDATE,
X_CREATED_BY in NUMBER DEFAULT NULL,
X_LAST_UPDATE_DATE in DATE DEFAULT NULL,
X_LAST_UPDATED_BY in NUMBER DEFAULT NULL,
X_LAST_UPDATE_LOGIN in NUMBER DEFAULT NULL,
X_FILE_EXT in VARCHAR2 DEFAULT NULL,
X_ALLOW_FILE_UPLOAD in VARCHAR2 DEFAULT NULL);
PROCEDURE UPDATE_ROW (X_MIME_TYPE_ID in NUMBER,
X_MIME_TYPE in VARCHAR2 DEFAULT NULL,
X_CP_FORMAT_CODE in VARCHAR2 DEFAULT NULL,
X_CTX_FORMAT_CODE in VARCHAR2 DEFAULT NULL,
X_LAST_UPDATE_DATE in DATE DEFAULT SYSDATE,
X_LAST_UPDATED_BY in NUMBER DEFAULT NULL,
X_FILE_EXT in VARCHAR2 DEFAULT NULL,
X_ALLOW_FILE_UPLOAD in VARCHAR2 DEFAULT NULL);
PROCEDURE DELETE_ROW (X_MIME_TYPE in VARCHAR2,
X_FILE_EXT in VARCHAR2);
PROCEDURE SET_FILE_EXT (X_MIME_TYPE IN VARCHAR2,
X_FILE_EXT IN VARCHAR2);
X_LAST_UPDATE_DATE in DATE DEFAULT SYSDATE,
X_LAST_UPDATED_BY in NUMBER DEFAULT NULL);
PROCEDURE SET_ALLOW_UPLOAD (X_FILE_EXT IN VARCHAR2,
X_MIME_TYPE IN VARCHAR2,
X_ALLOW_FILE_UPLOAD IN VARCHAR2,
X_LAST_UPDATE_DATE in DATE DEFAULT SYSDATE,
X_LAST_UPDATED_BY in NUMBER DEFAULT NULL);
To insert a row into the fnd_mime_types table:
FND_FILE_MIME_TYPES_PKG.insert_row(x_rowid => xrow,
x_mime_type => 'application/mime_value',
x_created_by => <userid>,
x_last_updated_by => <userid>,
x_file_ext => 'ext',
X_ALLOW_FILE_UPLOAD => 'N');
To allow file upload:
FND_FILE_MIME_TYPES_PKG.set_allow_upload(x_file_ext => 'ext',
x_mime_type => 'application/mime_value',
x_allow_file_upload => 'Y');
To use the API fnd_file_mime_types_pkg.update_row first determine the mime_type_id of the record to be updated:
execute FND_FILE_MIME_TYPES_PKG.update_row(x_mime_type_id => 82,X_ALLOW_FILE_UPLOAD => 'Y');
Note: If changes do not immediately take effect, a stop and restart of the application tier may be required.
The AntiSamy Check feature was originally delivered in the Oracle E-Business Suite October 2011 Critical Patch Update (CPU) and updated in subsequent CPUs.
This enhancement leverages the AntiSamy libraries to validate HTML files that are uploaded using the Attachment or File Upload features. For more information on the AntiSamy Project, see the Open Web Application Security Project (OWASP) AntiSamy Project page at https://wiki.owasp.org/index.php/Category:OWASP_AntiSamy_Project.
This AntiSamy Check is available for both Oracle Application Framework and Oracle Application Object Library Attachment/File Upload functionality.
The feature is controlled by profile FND: Disable AntiSamy Filter (FND_DISABLE_ANTISAMY_FILTER). When this profile is set to 'No' (the default value), Oracle E-Business Suite will upload a cleaned-up version of a file with the message "The document you uploaded has been modified to remove restricted tags. Please check the document and replace it if necessary." The internal name of this message is FND_CLEAN_DOCUMENT_UPLOAD.
The AntiSamy check uses the policy file named fnd-antisamy-irec-1_3.xml under $JAVA_TOP/policies/antisamy. See the documentation for AntiSamy if you wish to restrict or relax the HTML tags that are allowed. See My Oracle Support Knowledge Document 122452.1, Global Customer Services Customization Guidelines.
AntiSamy HTML sanitizing logic parses the uploaded/attached HTML as a string and removes the malicious pieces of code from it. Oracle E-Business Suite assumes the character encoding of the HTML file as follows:
Character encoding written in the content-type meta tag in the HTML file.
The HTML file should have a meta tag to specify the HTML character encoding like the following example:
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
The character encoding name for this meta tag must be an IANA character encoding name.
FND_NATIVE_CLIENT_ENCODING profile option value.
If Oracle E-Business Suite cannot detect the character encoding from an HTML meta tag, it will get it from the profile option and assume it is equivalent to that of the HTML file.
To avoid the non-ASCII character corruption in HTML by AntiSamy HTML sanitizing, make sure the HTML file being uploaded has a "content-type" meta tag with the right character encoding. If corrupted characters are seen in an uploaded/attached file, check if the HTML is well-formed and has a meta tag for character encoding. The character encoding detection may fail in the following circumstances:
No character encoding information is specified in a meta tag.
A meta tag does not exist in <head> section.
<head> or </head> tag is missing.
Failure to parse the meta tag because the HTML is malformed. For example, the meta tag does not start with "<" or does not end with ">" or "/>".
When there are multiple "content-type" meta tags in one HTML file, the very first one is used. If it fails to parse the very first one, the character encoding detection logic assumes there is no valid character encoding information in the HTML. The rest of the "content-type" meta tags will not be parsed.
If the character encoding cannot be described in an HTML "content-type" meta tag for some reason, use the FND_NATIVE_CLIENT_ENCODING profile option value to specify the HTML character encoding. Note that the value of FND_NATIVE_CLIENT_ENCODING is generally referred in text file uploading, downloading, and data exporting; and not for HTML file uploading/attachment only. Thus, the FND_NATIVE_CLIENT_ENCODING value must be set carefully.
Profile option FND: Attachment URL Allowed Protocols (FND_ATTACHMENT_ALLOWED_PROTOCOLS) contains a comma-separated list of protocols that are allowed for Attachment URLs.
The default value is https,http.
Use this profile to specify which protocols are allowed for Attachment Web documents. If a user attempts to open an Attachment Web page with a protocol that is not in the list, an error message is displayed.
For more information on the FND: Attachment URL Allowed Protocols profile option, see "Setting Profile Options" in the Oracle E-Business Suite Setup Guide.
You can choose which antivirus software to use to scan attachments files and file uploads in Oracle Application Framework and Oracle Forms applications. For more information, see: Internet Content Adaptation Protocol (ICAP) Antivirus Software Configuration, Oracle E-Business Suite Setup Guide.
Security policy must balance risk of attack, cost of defense and value of data protected. This section contains recommendations that improve security, but may not be appropriate for every deployment.
The technical reference paper in My Oracle Support Knowledge Document 1573912.1, All About Oracle Payments Release 12 Wallets And Payments Data Encryption, describes the credit card encryption features available in Oracle E-Business Suite. The feature is part of Release 12, but needs to be explicitly turned on.
Encryption of credit card numbers is one of many requirements for PCI PA-DSS compliance.
In many production environments, it is part of normal operational procedure to periodically create clones (copies) of production databases for various purposes. These copies are typically used for performance test by DBAs or developers or to test upgrade/patching of the production database.
When these cloned copies of production databases are to be used outside the group of trusted production administrators, there will be concerns about the confidentiality of the data contained in the database as data scrambling routines are typically run on the cloned copy before it is handed over to development. The data scrambling protects the confidentiality of production data such as employee data (Name, Address, Social Security Number, Compensation details) customer data (Name, Address, Credit Card info) and other data considered confidential.
To ensure the integrity of the production database you must also change all the passwords in the clone to ensure that it will not be possible to retrieve passwords from the cloned instance that could be used to compromise the production database either by gaining administrative access or by allowing someone to impersonate another user.
See My Oracle Support Knowledge Document 419475.1, Removing Credentials from a Cloned EBS Production Database, for an example of how to remove production credentials and bootstrap new credentials in a cloned copy of your production database. The steps in Document 419475.1 should be incorporated in your local cloning procedures.
A server can pass additional information with a response using HTTP headers. HTTP security headers can provide additional protection against attacks and security vulnerabilities.
The following table lists HTTP security response headers that are certified for use with Oracle E-Business Suite.
| HTTP Header | Description | Oracle E-Business Suite Configuration and Reference |
|---|---|---|
X-Frame-Options: SAMEORIGIN |
Response header to avoid clickjacking attacks by preventing other sites from embedding (framing) your content. | In Oracle E-Business Suite Release 12.2, we introduced protections against clickjacking by setting the X-Frame-Options HTTP header for all pages. This is enabled by default with the following configuration line in the Oracle HTTP Server (OHS) oracle_apache.conf file:
Header set X-Frame-Options SAMEORIGIN Note: If you require the ability to frame Oracle E-Business Suite pages from a site other than the Oracle E-Business Suite site, you may have to temporarily disable this header while working on a permanent solution (such as by rehosting or proxying). To temporarily disable the header, comment out the entry in the |
X-Content-Type-Options: nosniff |
Response header that prevents browsers from attempting to guess the MIME type of a file by looking at its content. | As of the October 2018 Critical Patch Update (CPU), this configuration is enabled by default. See My Oracle Support Knowledge Document 2445688.1, Oracle E-Business Suite Release 12 Critical Patch Update Knowledge Document (October 2018), for more information on the October 2018 CPU. |
| Strict-Transport-Security (HTTP Strict Transport Security) | Response header that specifies that the site should only be contacted using HTTPS. | In Oracle E-Business Suite Release 12.2, we introduced manual configuration to enable HSTS. For additional information regarding HSTS, refer to My Oracle Support Knowledge Document 1367293.1, Enabling TLS in Oracle E-Business Suite Release 12.2.
Caution: We recommend that you implement the HSTS only after testing that it does not break any customized code or third-party integrations. |
| Cookie Domain Scoping | Code that specifies the scope of where the browser will send the cookie. | In Oracle E-Business Suite Release 12.2, we introduced a configuration option for the domain attribute for the Oracle E-Business Suite ICX session cookie. Manual configuration is required to use this feature. See the Cookie Domain Scoping section for additional information. |
secure Cookie Attribute |
A Set-Cookie response header attribute that prevents cookies from being sent with non-HTTPS requests. | ICX Session Cookie If you have enabled TLS for Oracle E-Business Suite, the secure cookie attribute is automatically added to the ICX session cookie (also known as the Oracle E-Business Suite session cookie) by default. TLS enablement for Oracle E-Business Suite is required for this configuration. For more information, see My Oracle Support Knowledge Document 1367293.1, Enabling TLS in Oracle E-Business Suite Release 12.2. JSESSIONID Cookie The JSESSIONID cookie is a generic Java session cookie set by the Oracle Applications Server. If your Oracle E-Business Suite web entry point is using HTTPS, follow the instructions in Configure the JSESSIONID Cookie. |
httpOnly Cookie Attribute |
A Set-Cookie response header attribute that prevents client side script from accessing the cookie. | ICX Session Cookie The HTTPOnly cookie attribute is set automatically for the ICX session cookie (also known as the Oracle E-Business Suite session cookie) when the following minimum requirements are met:
Refer to the following for additional information:
JSESSIONID Cookie The JSESSIONID is a generic Java session cookie set by the Oracle Applications Server. If you have enabled the Java Web Start option for running Forms for Oracle E-Business Suite, follow the instructions in Configure the JSESSIONID Cookie. |
samesite Cookie Attribute |
A Set-Cookie response header attribute that mitigates the risk of cross-site request forgery (CSRF) and information leakage attacks by asserting that the cookie should only be sent with requests initiated from the same registrable domain. | Patch 29672027:R12.TXK.C delivers context file parameters to enable and configure the SameSite cookie attribute. The parameters control the SameSite attributes for all cookies set from the HTTP entry point. After applying Patch 29672027, the default value of the SameSite cookie attribute (s_samesite_cookie_enabled) is set to # which disables the attribute. To enable the SameSite cookie attribute, you must set the value to "blank" as follows: s_samesite_cookie_enable=""You can also set the context variable s_samesite_cookie_attribute to 'strict' or 'lax'. By default, s_samesite_cookie_attribute is set to strict. For additional information, refer to: https://tools.ietf.org/html/draft-west-first-party-cookies-07. If Oracle Access Manager and your Oracle E-Business Suite system do not reside on the same domain, you will need to set the context variable s_samesite_cookie_attribute to 'lax'. If you are using iProcurement and plan to enable the SameSite cookie attribute, you must also apply Patch 31259179:R12.ICX.D and Patch 31840095:R12.FND.C. Based on the ATG level you are on, you may need to apply an FND one-off patch along with the iProcurement patch.
When enabling the SameSite cookie attribute, make sure to test integrations that are deployed in domains that differ from the Oracle E-Business Suite domain. A few examples of integrations that may have a different domain include iProcurement punchout or single sign-on integration with Oracle Access Manager or Identity Cloud Service. |
You should configure the JSESSIONID cookie if both of the following conditions are true:
The Oracle E-Business Suite web entry point is using HTTPS.
Java Web Start is enabled for running Forms on Oracle E-Business Suite.
Use the following sections to configure the JSESSIONID cookie on the OACORE managed server and Forms and the OAFM managed server.
Make a backup copy of the configuration in <EBS_ORACLE_HOME>/deployment_plans/oacore/plan.xml. You will be making modifications to this file.
Find the following entry in the plan.xml file:
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<value>false</value>
</variable>
And replace it with the following:
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<value>true</value>
</variable>
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieSecure</name>
<value>true</value>
</variable>
<variable>
<name>WeblogicApplication_SessionDescriptor_UrlRewritingEnabled</name>
<value>false</value>
</variable>
Then, find the following entry in the plan.xml file:
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<xpath>/weblogic-application/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
And replace it with the following:
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<xpath>/weblogic-application/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieSecure</name>
<xpath>/weblogic-application/session-descriptor/cookie-secure</xpath>
</variable-assignment>
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_UrlRewritingEnabled</name>
<xpath>/weblogic-application/session-descriptor/url-rewriting-enabled</xpath>
</variable-assignment>
Start your application.
Retest the configuration.
Make a backup copy of the configuration in <EBS_ORACLE_HOME>/deployment_plans/forms/plan.xml and <EBS_ORACLE_HOME>/deployment_plans/oafm/plan.xml. You will be making modifications to these files.
In each plan.xml file, find the following entries:
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieName</name>
<value>JsessionIDOAFM</value>
</variable>
Or
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieName</name>
<value>JsessionIDForms</value>
</variable>
And insert the following content after the entry:
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<value>true</value>
</variable>
<variable>
<name>WeblogicApplication_SessionDescriptor_CookieSecure</name>
<value>true</value>
</variable>
<variable>
<name>WeblogicApplication_SessionDescriptor_UrlRewritingEnabled</name>
<value>false</value>
</variable>
Then, find the following entry in the plan.xml file:
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieName</name>
<xpath>/weblogic-application/session-descriptor/cookie-name</xpath>
</variable-assignment>
And insert the following content after the entry:
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieHttpOnly</name>
<xpath>/weblogic-application/session-descriptor/cookie-http-only</xpath>
</variable-assignment>
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_CookieSecure</name>
<xpath>/weblogic-application/session-descriptor/cookie-secure</xpath>
</variable-assignment>
<variable-assignment>
<name>WeblogicApplication_SessionDescriptor_UrlRewritingEnabled</name>
<xpath>/weblogic-application/session-descriptor/url-rewriting-enabled</xpath>
</variable-assignment>
Information sent over the network and across the internet in clear text may be intercepted. Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are features that provide encryption of network traffic between the user's browser and the Oracle E-Business Suite web server. You should configure your Oracle E-Business Suite environment to use TLS for all inbound (HTTP), outbound, and loopback connections.
If you are enabling encryption for Oracle E-Business 12.2 for the first time, follow the instructions in My Oracle Support Knowledge Document 1367293.1, Enabling TLS in Oracle E-Business Suite Release 12.2.
As of October 2014, all versions of SSL are insecure and should not be used. Oracle highly recommends that Oracle E-Business Suite customers migrate from SSL to TLS 1.2. Migrating to TLS 1.2 will address recent security vulnerabilities (such as POODLE, FREAK, Logjam, and RC4 NOMORE). If you are migrating from SSL to TLS, follow the instructions in My Oracle Support Knowledge Document 1367293.1, Enabling TLS in Oracle E-Business Suite Release 12.2.
You should avoid all cipher suites with a key size less than 128-bit and any RC4-based cipher suite to avoid security vulnerabilities.
For more information, see My Oracle Support Knowledge Document 1367293.1, Enabling TLS in Oracle E-Business Suite Release 12.2.
If you expose any part of your Oracle E-Business Suite production system to the internet, you should consult My Oracle Support Knowledge Document 1375670.1, Oracle E-Business Suite Release 12.2 Configuration in a DMZ, for our advice for deploying external Oracle E-Business Suite products to the internet. This document describes the role of DMZs, external web tiers, external responsibilities, URL firewall, and reverse proxies in a secure external Oracle E-Business Suite deployment.
Deploy client/server components requiring direct connection to the Oracle E-Business Suite production database on secured, trusted servers rather than on end user desktop machines.
The majority of the Oracle E-Business Suite functionality available to end users does not require direct database access but is web-based. Web browser sessions connect to application tier servers running Oracle Fusion Middleware. The application tier servers then make the database connections.
If you have a well considered need to connect to the production database directly from a desktop, deploy a remote server environment based on Windows Server Terminal Services, Citrix, or Tarantella (now Oracle Secure Global Desktop).
The challenge is to make the server running the client/server program a trusted server. If the end user is running with administrator or power-user privileges, or has physical access to the host, it does not qualify as "trusted."
If the client/server tool uses DBC files these DBC files must be protected from the user while ensuring that the program run by the user has read access to the DBC file.
Further details are provided in the following sections: Add IP Restrictions / Enable Valid Node Checking, Activate Server Security, and Create DBC Files Securely.
Oracle ships seeded user accounts with default passwords. Change the default passwords immediately. Depending on product usage, some seeded accounts can or can not be disabled. Disable an application user account by setting the END_DATE for the account.
Do not disable the GUEST user account.
Do not disable the SYSADMIN user account until you have created other accounts with similar privilege.
Note that we ship a script named fnddefpw.sql. If you run this script as APPS, it will list the seeded accounts that still have the default password.
The following table lists the application users shipped with Oracle E-Business Suite Release 12 and indicates:
If it has a default password, you should Change
If you can safely Disable the account (if not used by your product mix)
If the account ships an impossible password (NoPwd)
If the account ships disabled (EndDT)
See description of the columns after the table and notice the footnotes following the table.
| Account | Product/Purpose | Change | Disable | NoPwd | EndDT |
|---|---|---|---|---|---|
| AME_INVALID_APPROVER | AME WF migration 11.5.9 to 11.5.10 | Y | Y | ||
| ANONYMOUS | FND/AOL - Anonymous for non-logged users | Y | Y | x | |
| APPSMGR | Routine maintenance via concurrent requests | N | Y | x | x |
| ASADMIN | Application Server Administrator | N | Y | x | x |
| ASGADM | Mobile gateway related products | Y | Y(a) | ||
| ASGUEST | Sales Application guest user | Y | Y(b) | ||
| AUTOINSTALL | AD | Y | Y | ||
| CONCURRENT MANAGER | FND/AOL: Concurrent Manager | Y | Y | x | |
| FEEDER SYSTEM | AD - Supports data from feeder system | Y | Y | x | |
| GUEST | Guest application user | Y(c) | N | ||
| IBE_ADMIN | iStore Admin user | Y | Y(d) | ||
| IBE_GUEST | iStore Guest user | Y | Y(d) | ||
| IBEGUEST | iStore Guest user | Y | Y(d) | ||
| IEXADMIN | Internet Expenses Admin | Y | Y | ||
| INDUSTRY DATA | N | Y | x | ||
| INITIAL SETUP | AD | Y | Y | x | |
| IRC_EMP_GUEST | iRecruitment Employee Guest Login | Y | Y | ||
| IRC_EXT_GUEST | iRecruitment External Guest Login | Y | Y | ||
| MOBILEADM | Mobile Applications Admin | Y | Y | ||
| MOBILEDEV | Mobile Applications Development | Y | Y | ||
| OP_CUST_CARE_ADMIN | Customer Care Admin for Oracle Provisioning | Y | Y | ||
| OP_SYSADMIN | OP (Process Manufacturing) Admin User | Y | Y | ||
| ORACLE12.[0-9].0 | Owner for release specific seed data | N | N | x | |
| PORTAL30 | Desupported Portal 3.0.x Account | Y | Y | ||
| PORTAL30_SSO | Desupported Portal 3.0.x Account | Y | Y | ||
| STANDALONE BATCH PROCESS | FND/AOL | Y | Y | ||
| SYSADMIN | Application Systems Admin | Y | N | ||
| WIZARD | AD - Application Implementation Wizard | Y | Y | ||
| XML_USER | Gateway | Y | Y |
(a) Required for Mobile Sales, Service, and Mobile Core Gateway components.
(b) Required for Sales Application.
(c) If the GUEST password is changed, set the AutoConfig variable s_guest_pass to the new value in the context file before running AutoConfig. AutoConfig must be run to propagate the new password to config files.
Note: The GUEST password must always be in UPPERCASE.
(d) Required for iStore.
In the table, an 'x' in the EndDT column means the account ships end-dated.
In the table, an 'x' in the NoPwd column indicates that the account ships with an "impossible password," this means that the password column in FND_USER contains a clear text string that is never a valid encrypted or hashed password. Thus it is not possible to login as this user, unless you change the password.
The "impossible" value can be "DUMMY," "INVALID," or "INTERNAL USER-NOLOGIN."
Note: If the "impossible" value is not "INVALID", FNDCPASS will log a "cannot decrypt" error which can be ignored. More recent R12 versions consistently use "INVALID."
You can easily identify the users with an impossible password as the length of the impossible password is shorter than the encrypted or hashed password. For example, this SQL statement will list users with an impossible password:
select USER_NAME,END_DATE,ENCRYPTED_USER_PASSWORD from FND_USER where length(ENCRYPTED_USER_PASSWORD)<30 order by 1;
In the table, a 'Y' in the Change column indicates that you should change the password for the account as it ships with a default password. A value of 'N' means that you do not have to change anything to get rid of a default password. If the account is used by your Oracle E-Business Suite product mix, you should change the default password to a password of your choosing, and according to the implementation guide for the product that requires it.
Traditionally, Oracle E-Business Suite has stored the password of the application users (FND_USERs) in encrypted form. Starting with release 12.0.4, it is possible to switch the Oracle E-Business Suite system to store hashed versions of the passwords instead.
To switch Oracle E-Business Suite to use hashed passwords, you must use the AFPASSWD command-line utility in MIGRATE mode. See the Oracle E-Business Suite Maintenance Guide for more details.
Note: This process is irreversible.
For local application users, the profile option settings below support strong passwords, account lockout after too many failed logons, and session inactivity timeout.
| Profile Option Internal Name | Recommended Value |
|---|---|
| SIGNON_PASSWORD_LENGTH | 8 |
| SIGNON_PASSWORD_HARD_TO_GUESS | YES |
| SIGNON_PASSWORD_NO_REUSE | 180 |
| SIGNON_PASSWORD_CASE | Sensitive |
| SIGNON_PASSWORD_FAILURE_LIMIT | 5(a) |
| ICX_SESSION_TIMEOUT | 30 |
| SIGNON_PASSWORD_CUSTOM | implement(b) |
(a) Setting automatic account locking after N failed attempts make for a simple denial of service attack. If you set this profile option monitor the FND_UNSUCCESSFUL_LOGINS table.
(b) If your corporate password policy cannot be expressed using the above parameters, you may implement a custom password validation function and register it with Oracle E-Business Suite. See Customizing Password Validation.
Security policy must balance risk of attack, cost of defense and value of data protected. This section contains recommendations that improve security, but may not be appropriate for every deployment.
If your corporate password policy cannot be expressed using the "Sign-On" parameters as found in Tighten Logon and Session Profile Options, you can implement a custom function for validating new passwords.
To customize password validation create a Java class that implements the oracle.apps.fnd.security.PasswordValidation Java interface. The interface requires three methods:
public boolean validate(String user, String password
This method takes a user name and password, and returns True or False, indicating whether the user's password is valid or invalid, respectively.
public String getErrorStackMessageName()
This method returns the name of the message to display when the user's password is deemed invalid (for example, the validate() method returns False).
public String getErrorStackApplicationName()
This method returns the application short name for the aforementioned error message.
After writing the customized password validator, set profile option SIGNON_PASSWORD_CUSTOM to the full name of the class. If the name of the Java class is yourco.security.AppsPasswordValidation, then the value of SIGNON_PASSWORD_CUSTOM must be "yourco.security.AppsPasswordValidation". Note, this class must be loaded into the Application database using the loadjava command.
Oracle User Management (UMX) provides a common user registration flow in which a user can enter a new password or select to have one generated randomly. UMX uses workflow to drive the registration process once a request has been submitted. See UMX documentation for more details.
When users share one account, the system cannot identify which user performs a function, preventing accountability. Users share the same functions or permission sets, while the system tracks individual user actions.
Concurrent manager passes the APPS schema password to concurrent programs on the command line. Because some operating systems allow all machine users to read a program's command line arguments, the password may be intercepted. To prevent this, define the concurrent program executable as a HOST program in the concurrent program executable form. Enter ENCRYPT in the Execution Options field of the concurrent programs window when defining a concurrent program using this executable. ENCRYPT signals the concurrent manager to pass the user name/password in the environment variable FCP_LOGIN. Concurrent manager leaves argument $1 blank.
To prevent the user name/password from being passed, enter SECURE in the Execution Options field. With this change, concurrent manager does not pass the user name/password to the program. This means that the program will have to get the database credentials some other way if it needs to connect to the database.
Traditionally, the operator starting and stopping the application services needed to know the APPS user name and password in order to start the application services on an application tier that was running the concurrent manager.
Starting with Oracle E-Business Suite Release 12.1.3, it is possible to create an applications user (FND User) with the responsibility Concurrent Manager Operator and use this user's user name and password start and stop the application services.
This is implemented by:
Creating a new user (for example, CONCOPER) and assigning the "Concurrent Manager Operator" responsibility to this user
On the application tier, update the following 4 variables in the AutoConfig context file:
| AutoConfig Variable | New Value |
|---|---|
| s_cp_user | CONCOPER (or the one you created) |
| s_cp_password_type | AppsUser |
| s_cp_resp_shortname | FND |
| s_cp_resp_name | Concurrent Manager Operator |
Run AutoConfig on the application tier(s)
Following this change, the application tier services can be started and stopped by calling adstrtal.sh and adstpall.sh with the -secureapps option and the script will prompt for the Application user's user name and password rather than the APPS user name and password.
For example:
[applmgr@app01]$ adstrtal.sh -secureapps Enter the Applications username: CONCOPER Enter the Applications password:
Oracle E-Business Suite Release 12 is deployed in a multi-tier configuration with one database server and an application tier with many possible application servers. The application servers include Apache JSP/Servlet, Forms, Discoverer. Any program which makes a SQLNet connection to the Oracle Applications database needs to be trusted at some level. The Server Security feature ensures that FNDLogin connections originate from trusted machines.
Additional Information: Concerning Oracle Discoverer, see also My Oracle Support Knowledge Document 2277369.1, Oracle E-Business Suite Support Implications for Discoverer 11gR1.
The Application Server Security feature is activated by default, all you should do is verify that the setting is set to SECURE.
This setting is controlled by the AutoConfig variable s_appserverid_authentication.
Application Server Security has three states:
OFF - Inactivates Server Security. Server and code IDs are not checked. Appropriate for machines completely under an administrator's control. OK for development systems without production data.
ON - Equivalent to OFF from a security perspective. Not recommended for production systems.
SECURE - Recommended; only registered application servers and trusted code modules may connect.
Check the Server Security status using the STATUS command in the AdminAppServer utility before activating server security to ensure that all desired application servers have been registered. For details, see: Administering Server Security, Oracle E-Business Suite Setup Guide, Oracle E-Business Suite Setup Guide.
Another way to verify that server security is set to secure is to run the following SQL query while connected as APPS:
SQL> select NODE_NAME,SERVER_ID,SERVER_ADDRESS from FND_NODES
where SERVER_ADDRESS = '*' ;
NODE_NAME SERVER_ID SERVER_ADDRESS
-------------- ------------- ---------------
AUTHENTICATION SECURE *
Previous versions of documentation documented how to create DBC files for the Oracle E-Business Suite application tiers using the AdminAppServer utility. Oracle E-Business Suite Release 12 already does this automatically through AutoConfig, so you should never have to do this manually.
However when creating DBC files for use by desktop installations or for other, non-Oracle E-Business Suite application tiers that must connect to the Oracle E-Business Suite database, you must use the AdminDesktop utility to create the DBC file.
Examples of such external hosts are a webservice host or a BPEL service host.
Creating DBC files for these external, non-Oracle E-Business Suite tiers involves:
Running AdminDesktop on the Oracle E-Business Suite tiers to create the DBC file
Copying the DBC file to the external tier
Configuring the external tier to use the DBC file as a data source
Use of AdminDesktop - and documentation of any patches needed - can be found in My Oracle Support Knowledge Document 974949.1, Oracle E-Business Suite Software Development Kit for Java.
When creating DBC files make sure to make them IP address specific and that the file permissions are set to 600 (-rw-------).
Oracle E-Business Suite Release 12 support integration with a Single Sign-On (SSO). For more information on Single Sign-On deployments, refer to My Oracle Support Knowledge Document 376811.1, Integrating Oracle E-Business Suite Release 12 with Oracle Internet Directory and Oracle Single Sign-On.
Follow the instructions in Changing the Oracle WebLogic Server Administration User Password, Oracle E-Business Suite Setup Guide to change the default password for the Oracle WebLogic administration user. The default password should be changed immediately.
Some forms and pages in Oracle E-Business Suite allow a user to modify the functionality of the applications by specifying values such as SQL statements, SQL fragments such as WHERE clauses, HTML strings, and operating system commands or environment variables. These screens may constitute a security risk if used in an unauthorized fashion. Most of these screens are accessible only from system administration menus and responsibilities, where availability should be limited to a very few trusted users. You should eliminate or minimize access to these screens in a production system and know exactly which users have access to these screens.
There are several types of these sensitive pages in Oracle E-Business Suite, and they are controlled by different mechanisms. They can be grouped them into the following categories:
Oracle Forms Controlled by Function Security
HTML Pages Controlled by Function Security
Functionality Controlled by Profile Options
Pages Controlled by JTF Permissions and Roles
My Oracle Support Knowledge Document 1334930.1, Sensitive Objects and Administrative Pages in Oracle E-Business Suite, lists these forms, pages, profile options and includes a description of how to determine who has access by interactively using UMX User Management or by running SQL scripts.
Set the recommended values for the security-related profile options as listed in the following table. It is recommended that these settings are applied at site level. In general, the values for the following security-related profile options should not be set to any non-recommended value at any other level than site.
| Profile Option Name | Code (Internal Name) | Recommended Value | Comments and References |
|---|---|---|---|
| FND: Diagnostics | FND_DIAGNOSTICS | No | The recommended value ensures there are no verbose error messages. The recommended value prevents information leakage and ensures that details of unexpected error messages are not sent to the user. Generally, users should not have this profile option enabled. If required, FND: Diagnostics should only be set at the user level to provide diagnostics to Support. |
| Utilities:Diagnostics | DIAGNOSTICS | No | See "Utilities: Diagnostics" in the Oracle E-Business Suite Setup Guide. If required, this should only be set at the user level. Generally, users should not have this profile enabled. |
| Personalize Self-Service Defn | FND_CUSTOM_OA_DEFINITION | No | Only set at user level for users that require this functionality. Generally, users should not have this profile enabled. |
| Attachment File Upload Restriction Default | FND_SECURITY_FILETYPE_RESTRICT_DFLT | No | The recommended value allows for only file types with ALLOW='Y' to be uploaded. That is, only file types in which the ALLOW flag are explicitly set to 'Y' in fnd_mime_types are allowed for upload. See File Type Validation. |
| FND: Disable AntiSamy Filter | FND_DISABLE_ANTISAMY_FILTER | No | The recommended value enables AntiSamy checks. See AntiSamy Check. |
| Restrict Text Input | FND_RESTRICT_INPUT | Yes | The recommended value enables additional validation of parameters. This profile option provides a defense in depth filter against XSS (Cross Site Scripting) and other HTML injection attacks. When enabled, it invokes an HTML tag filter on input fields and parameters. Test any input fields or parameters in which you expect to be passing HTML or HTML fragments. |
| BNE Allow No Security Rule | BNE_ALLOW_NO_SECURITY_RULE | No | The recommended value prevents access to global integrators (integrators without a security rule). |
| Export Secure Output Format | FND_EXPORT_FORMAT | Space Escape | This profile allows you to define the escape character for exported data to prevent a CSV injection which would allow a lead character to run a macro and corrupt data downloaded to Excel. The recommended value "Space Escape" is the default value. This can be changed to any other value except "Do Not Escape". |
| FND: Authn Service Token Scope | FND_AUTHN_SRVC_TOKEN_SCOPE | Header Only | The recommended value for the profile will set the ICX cookie only in the response header of the mLogin REST service and will not return the cookie details in the response payload. If you have custom code that calls the mLogin REST service and the cookie details are required in the response payload, then you must temporarily change the profile value to "Header and Body" to avoid failures when running the custom code. The value "Header and Body" will set the ICX cookie in the header and returns the cookie name and value in the payload. For security and privacy purposes, we recommend that you modify your custom code to retrieve the cookie details from the response header as soon as possible. After your custom code has been updated to meet recommended security standards, you should change the FND: Authn Service Token Scope (FND_AUTHN_SRVC_TOKEN_SCOPE) profile to "Header Only" at the site level. |
The Critical Security Profile Values security guideline in the Secure Configuration Console checks these profile options to ensure recommended settings are applied. See Checked Security Guidelines for more information on this and other security guidelines checked by the Secure Configuration Console.
When web servers have been assigned a server trust level, the system may restrict access to a responsibility based upon that trust level. Three trust levels are supported:
Administrative
Normal
External
Typically, administrative web servers are used exclusively by system administrators, are considered secure and have full application access with few limitations. Normal web servers are those used by employees within a company's intranet and requiring non-administrative responsibilities. Lastly, customers or employees outside of a company's firewall connect to external servers. These have access to a small set of responsibilities.
To assign a trust level to a web server, the administrator sets the NODE_TRUST_LEVEL profile option. This option, a server-based profile option, can be set to either 1, 2 or 3. The number 1 means administrative, 2 means normal, and 3 means external. To avoid having to set the NODE_TRUST_LEVEL for every single web server, administrators may wish to set the NODE_TRUST_LEVEL profile to some default level of trust at the site level. If no value is set for NODE_TRUST_LEVEL, the web server is assumed to have a trust level of 1 (administrative).
When a user logs on to Oracle Applications using a web server, the system determines which responsibilities are valid for that user, and of those responsibilities, which can be accessed from that particular web server. The system returns only responsibilities appropriate for the web server Trust Level.
To restrict access to a responsibility, set the Application Server Trust Level profile option value for that responsibility to be the number 1, 2 or 3. This indicates that only web servers with the same or greater ordinal trust level may access that responsibility.
For example, a responsibility with an Application Server Trust Level set to 1 (administrative) would only be available if the web server has its Application Server Trust Level set to 1 (administrative), as well. A responsibility with Application Server Trust Level set to 2 (normal) would only be available if the web server has its Server Trust Level set to either 1 (administrative) or 2 (normal).
Responsibilities or applications with the specified level of trust can only be accessed by an application server with at least the same level of trust. Users can see this profile option, but they cannot update it. The system administrator access is described in the following table:
| Level | Visible | Allow Update |
|---|---|---|
| Site | Yes | Yes |
| Application | Yes | Yes |
| Responsibility | Yes | Yes |
| User | No | No |
For more information on how to enable and use the above security features, refer to Part I of the Oracle E-Business Suite Security Guide.