4 Securing EnterpriseOne System Components

This chapter contains the following topics:

4.1 Overview of JD Edwards EnterpriseOne System Components

This illustration shows the various components of a JD Edwards EnterpriseOne configuration:

Description of enterpriseone_architecture.png follows
Description of the illustration ''enterpriseone_architecture.png''

4.2 Database Security

EnterpriseOne stores all system and business data in a supported relational database. Therefore, it is extremely important that you carefully set up security for the Database Server.

4.2.1 Revoke PUBLIC Access to Installed EnterpriseOne Database Tables

JD Edwards EnterpriseOne Applications release 9.1 and prior include database platform packs that install EnterpriseOne tables with PUBLIC level access. PUBLIC acts as a default role granted to every database user. Oracle provides platform specific tools to revoke PUBLIC access from EnterpriseOne database tables. Implementing the platform specific tools enables you to ultimately grant access for each database table to one or more database roles while revoking access to PUBLIC. The database roles will be associated to each EnterpriseOne system (proxy) user as deemed appropriate. This ensures that the database tables are accessible by only database users associated to a particular database role.

The following sections provide links for the platform-specific tools that you can use to revoke PUBLIC access from EnterpriseOne tables for the supported databases: Oracle, Microsoft SQL Server, and IBM databases.

4.2.1.1 EnterpriseOne PUBLIC Shutdown Scripts for Oracle Database

Oracle provides a set of scripts in SAR 8289283 that you can run to revoke PUBLIC access in EnterpriseOne tables installed in an Oracle Database. See Doc ID 748163.1 in My Oracle Support for instructions on how to download SAR 8289283 and run the scripts. Use the following URL to access and sign in to My Oracle Support:

https://support.oracle.com

4.2.1.2 EnterpriseOne PUBLIC Shutdown Scripts for Microsoft SQL Server

Oracle provides a set of scripts in SAR 8090565 that you can run to revoke PUBLIC access in EnterpriseOne tables installed in a Microsoft SQL Server Database. See Doc ID 748159.1 in My Oracle Support for instructions on how to download SAR 8090565 and run the scripts. Use the following URL to access and sign in to My Oracle Support:

https://support.oracle.com

4.2.1.3 DB2 for IBM i PUBLIC Shutdown Using SETOWAUT

Oracle provides a SETOWAUT toolkit for the IBM i platform that enables you to restrict access to database tables to only EnterpriseOne authorized users. The SETOWAUT toolkit is the equivalent PUBLIC shutdown methodology for the IBM i platform. Furthermore, the EnterpriseOne middleware and command set used to control the EnterpriseOne solution is also restricted permitting only authorized users to control and use this comprehensive program set. For instructions on how to the use of the SETOWAUT toolkit, see "Administering JD Edwards EnterpriseOne Database Security for IBM i" in the JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide.

4.2.2 Limit Access to Query Tools

Database user passwords should be strong and end users should have limited access to Query Tools.

4.3 File System Security

The JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide contains security instructions for UNIX and Microsoft Windows servers that you must follow to ensure that only certain EnterpriseOne files can be accessed by the operating system. See the following sections for more information:

4.4 Encryption of Sensitive Information in Configuration Files

With EnterpriseOne Tools Release 9.1 Update 4, sensitive information such as passwords can be encrypted in EnterpriseOne configuration (ini) files. See Chapter 6, "Encrypting Sensitive Data in EnterpriseOne Configuration Files (Release 9.1 Update 4)" in this guide for more information.

4.5 Deployment Server Security

The Deployment Server typically contains EnterpriseOne source code, package build areas, install packages, and licensing information.

4.5.1 Limit Access to System

Use these guidelines when setting up security for the Deployment Server:

  • Only allow system administrators to log on to the Deployment Server.

  • Do not place shared services such as printing or DNS services on this host.

  • Run only EnterpriseOne on this machine for software installs and upgrades.

  • Do not create user accounts on this machine.

  • Give full access to the media object queue directory for only one user account that is accessing this directory from the EnterpriseOne HTML Server when you are not accessing media objects from a Microsoft Windows client.

  • Limit access to PrintQueue directory.

4.5.2 Secure Configuration File

The Deployment Server configuration file (JDE.INI) might contain the override password for the default database user to connect to EnterpriseOne data sources when doing an installation, upgrade, or applying a software update. Therefore, you need to secure this file using operating system security such as Microsoft Windows security, UNIX object security, or IBM i object security. After a successful install, upgrade, or software update, remove the [DSPWD] section from JDE.INI.

4.5.3 Secure Log Files

You should give only certain users access to view Deployment Server log files (error and debug), as these files might contain sensitive information about the user and location of the database.

4.6 JD Edwards EnterpriseOne Enterprise Server Security

The Enterprise Server (otherwise known as the business logic server) is used as middleware to run various functions such as business functions and reports. In addition, it functions as the security server. You must secure this server so that only configurable network computing (CNC) administrators have access to it.

4.6.1 Limit Remote Access

You should prohibit or severely limit remote session access and remote session control for the Enterprise Server.

4.6.2 Secure Configuration File

The Enterprise Server configuration file (JDE.INI) contains the user ID and password. Therefore, you should secure this file using operating system security such as Microsoft Windows security, UNIX object security, or IBM i object security.

Caution:

Implementing security on these files will prevent Server Manager from modifying configuration settings within these files.

4.6.3 Limit Access to Administer EnterpriseOne Services

You should give only certain users authority to start and stop EnterpriseOne processes and to run scripts because this authority also requires access to the JDE.INI file, which contains the database password. Do not give users access to update EnterpriseOne script files for starting and stopping services.

4.6.4 Secure Log Files

You should give only certain users access to log files (error and debug) on the Enterprise Server. These files might contain sensitive information about the user and the location of the database.

Caution:

Implementing security on these files will prevent Server Manager from being able to display the logs.

4.6.5 Limit Access to BSFN Trace Logs

Change the ClientLog setting to 0 in the [DEBUG] section of the JDE.INI so that Call Object kernel does not send the business function (BSFN) server logs back to the workstation after executing the BSFN calls. Refer to the JD Edwards EnterpriseOne Upgrade Guides for more information about this setting.

4.6.6 Limit Access to PrintQueue Directory

The Enterprise Server stores all the report output in the PrintQueue directory. You should give only certain users access to the PrintQueue directory.

4.6.7 Use Security Server

In a production environment, always use the security server. You can run business logic on the Enterprise Server without using a security server when logged in with a user ID that is also a database user.

4.7 JD Edwards EnterpriseOne HTML Server Security

The JD Edwards EnterpriseOne HTML Server is a critical component of the EnterpriseOne system. It is used as a gateway by all web users to access EnterpriseOne. EnterpriseOne supports Oracle WebLogic Server and IBM WebSphere Application Server for a web solution.

4.7.1 Oracle WebLogic Server

If you have deployed an Oracle WebLogic Server, take the appropriate steps to make the installation more secure. See "Security" in the Oracle Fusion Middleware Information Roadmap for Oracle WebLogic Server document.

4.7.2 IBM WebSphere

If you have deployed an IBM WebSphere Application Server, follow IBM's recommendations to make the installation more secure:

http://www.redbooks.ibm.com/abstracts/sg247660.html (WebSphere 7)

http://www.ibm.com/developerworks/websphere/zones/was/security/ (WebSphere 8.5)

4.7.3 Secure Configuration Files

The EnterpriseOne HTML Server uses these configuration files:

  • JAS.INI

  • JDBj.INI

  • JDELOG.PROPERTIES

In addition, the web server can have a Tokengen.ini in a single sign-on environment. These files contain sensitive information that should not be available to all users, so you should use operating system security to secure the files.

Caution:

Implementing security on these files will prevent Server Manager from modifying configuration settings within these files.

4.7.4 Secure Log Files

You should give only certain users access to log files (error and debug) on the EnterpriseOne HTML Server. These files might contain sensitive information about the user and the location of the database.

Caution:

Implementing security on these files will prevent Server Manager from being able to display the logs.

4.7.5 J2EE Session Timeout Setting

After a user signs in, he or she can stay connected as long as the sign-in time allows and as long as the browser does not sit idle for longer than the timeout interval. A timeout interval specifies how long the user's machine can remain idle before the J2EE application server automatically disconnects the user from the application.

Set up the policy for inactive session timeout and set this value accordingly. For the web application server, this value is 30 minutes by default. Refer to the JD Edwards EnterpriseOne Tools HTML Server Reference guides for more information on setting the timeout values.

4.7.6 Limit Access to Media Object Queue Directory

The EnterpriseOne HTML Server caches the media object files under /jde/moqueue/ directory of the installed web application. The operating system user for whom the web application server process is running must have full access to this directory. Secure access for all other users to this directory on the web server. You should use media object security in EnterpriseOne to secure access to media object attachments from EnterpriseOne applications. Refer to Setting Up Authorization Security with Security Workbench in this guide for more information on setting up media object security.

4.7.7 Set Up FTP User Access to Media Objects

You can configure the system to use Windows NT Share or FTP protocol to access media object files from media object queue directories. The FTP user ID and password should be provided in the JAS.INI file to access media object queue directories. The FTP user or operating system user (in case of Windows NT Share) for whom the web server process is running should have full access to media object queue directories. You should limit the access to any other directories on the server where the media object queue directories are located for this FTP user or operating system user. All other users should not have access to media object queue directories when users are not accessing media objects from the Windows client.

4.7.8 Use SSL (HTTPS) Between Browser and Web Server

Information sent over the network and across the internet in clear text can be intercepted. The Secure Socket Layer (SSL) protocol, developed by Netscape Corporation, is an industry-accepted standard for network transport layer security. SSL is supported by all currently available web servers and web browsers. You should configure SSL on the EnterpriseOne HTML Server, especially in an internet environment.

Refer to "Configuring Secure Socket Layer with the HTML Server" in the JD Edwards EnterpriseOne Tools HTML Server Reference guides for more information on setting up SSL with an EnterpriseOne HTML Server running on Oracle WebLogic Server or IBM WebSphere Application Server.

Disable non-secure HTTP on the web application server after making sure that HTTPS is set up and working properly. Refer to the Network Infrastructure Security section in this guide for information about setting up network security in an internet environment.

4.7.9 HTTP Server Level

This section contains security considerations for the HTTP Server on the EnterpriseOne HTML Server.

4.7.9.1 Turn Off Directory Listing

Directory indexes display the contents of a directory if there is no index.html or similar file available. Disabling this entry prevents an intruder from viewing the files in a directory and potentially finding a file that could provide access to the system. Refer to the HTTP Server documentation to disable this feature in the web server configuration file.

4.7.9.2 Disable HTTP TRACE

The HTTP TRACE request method causes data to be returned to the client after it is retrieved by the server. The TRACE process can open up the system to malicious applications that can send the information to a third party site. Therefore, it is recommended that you disable HTTP TRACE. Refer to the security documentation for your application server for more information.

4.7.9.3 Deprecate Old Certificates

Certificates have a specified period of time in which they are valid. After the specified period of time has passed, a new certificate must be issued. Therefore, you should delete old certificates, as well as delete any certificates that have become compromised or corrupted.

4.7.10 Denial-of-Service Attacks

Denial-of-service (DOS) attacks can occur when a large number of poorly formed requests are sent to servlets. You can reduce the impact of DOS attacks, but it is impossible to prevent them. If an attacker throws enough data at a server to continuously use all the available network bandwidth, it will crowd out legitimate traffic, regardless of how the software is configured. Denial of service can only be handled at an application server level. To configure to reduce the impact of denial of service attacks, refer to the security documentation for your application server.

4.8 Portal Server Security

EnterpriseOne provides single sign-on support from the Collaborative Portal (IBM Portal) and Oracle WebCenter Spaces. Both portals use token-based authentication for achieving single sign-on with EnterpriseOne.

Refer to Chapter 11, "Setting Up JD Edwards EnterpriseOne Single Sign-On" for more information.

4.8.1 Collaborative Portal

A single sign-on token is generated by Collaborative Portal. You should set up a new node to support single sign-on for the Collaborative Portal server. You can create a single sign-on node configuration using the EnterpriseOne SSO application.

Oracle recommends setting up an SSL configuration for the Collaborative Portal. For instructions, see "Configuring the WSRP Consumer portal for SSL" on the IBM WebSphere Portal website:

http://www-10.lotus.com/ldd/portalwiki.nsf/xpDocViewer.xsp?lookupName=IBM+WebSphere+Portal+7+Product+Documentation#action=openDocument&res_title=Securing_WSRP_by_SSL_for_a_Consumer_portal_wp7&content=pdcontent

4.8.2 Oracle WebCenter Spaces

With an EnterpriseOne single sign-on setup for Oracle WebCenter Spaces, a single sign-on token is generated by the EnterpriseOne provider server. The provider server can be an Oracle WebLogic Server or IBM WebSphere Application Server and can be used as a standalone HTML Server. You should set up a new node for supporting single sign-on from the provider server. You should create a single sign-on node configuration using the EnterpriseOne SSO application.

The TokenGen.ini file contains node name and node password in plain text. You need to secure this file using operating system security.

In addition to the above recommendations, follow the guidelines in the JD Edwards EnterpriseOne HTML Server Security section in this guide to secure your web environment.

Oracle recommends setting up an SSL configuration for Oracle WebCenter Spaces. For instructions, see "Securing the WebCenter Spaces Connection to Portlet Producers with SSL" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter Portal:

https://docs.oracle.com/cd/E28280_01/webcenter.1111/e12405/wcadm_security_ssl.htm#WCADM6449

4.9 Transaction Server Security

EnterpriseOne event functionality provides an infrastructure that can capture EnterpriseOne transactions in various ways and provides real-time notification to third-party software, end users, and other Oracle systems such as Customer Relationship Management (CRM).

4.9.1 Secure Configuration Files

The Transaction Server uses the bootstrap user and password from JDBj.INI in install_directory/E1TranSrv/cfg directory. Secure this file, as well as other configuration files (JAS.INI and JDELOG.PROPERTIES), using operating system security.

Caution:

Implementing security on these files will prevent Server Manager from modifying configuration settings within these files.

4.9.2 Secure Log Files

You should give only certain users access to view Transaction Server log files (error and debug), as these files might contain sensitive information about the user and location of the database.

Caution:

Implementing security on these files will prevent Server Manager from being able to display the logs.

4.10 Business Services Server Security

EnterpriseOne provides authentication security to ensure that published business service users are authenticated in EnterpriseOne. The Business Services Server uses the EnterpriseOne Login Module as the authentication mechanism for authenticating users against the security server.

To set up security for the Business Services Server, see "Configuring Business Services Server Security" in the JD Edwards EnterpriseOne Tools Business Services Server Reference Guide. This chapter contains instructions on how to implement security for the Business Services Server, which can run on Oracle WebLogic Server or IBM WebSphere Application Server.

4.10.1 Secure Log Files

You should give only certain users access to view business services log files, as these files might contain sensitive information about the user and location of the database.

Caution:

Implementing security on these files will prevent Server Manager from being able to display the logs.

4.11 Oracle BI Publisher Server Security

The Oracle BI Publisher Server and the EnterpriseOne HTML Server must be within the same firewall to have two-way web service and HTTP communication.

To create an interactive BI Publisher report, a user must be able to sign on to both BI Publisher and to the EnterpriseOne database. The connection string for the data source, along with the EnterpriseOne JDBC Driver configuration, specifies the database that BI Publisher will access when creating and running interactive reports. At the time that the JDBC driver is configured, it is highly recommended that you select the Use Proxy Authentication option for the data source. Using proxy authentication assumes that the user IDs in BI Publisher and EnterpriseOne are the same, either by duplication or by using Lightweight Directory Access Protocol (LDAP).

Refer to "Oracle BI Publisher and JD Edwards EnterpriseOne Security" in the JD Edwards EnterpriseOne Tools BI Publisher for JD Edwards EnterpriseOne Guide for instructions on how to configure Oracle BI Publisher with EnterpriseOne.

4.11.1 Additional BI Publisher Server Security Considerations

For EnterpriseOne integrations with BI Publisher, it is important to note the following security-related considerations:

4.12 Mobile Applications Server Security

EnterpriseOne mobile applications can be installed on the same WebLogic Server as the Business Services Server or on a separate server. If installed on the same server and you have not already set up security for the Business Services Server, see "Configuring Business Services Server Security" in the JD Edwards EnterpriseOne Tools Business Services Server Reference Guide for instructions on how to properly secure the server.

If you installed mobile applications on a separate WebLogic Server than the Business Services Server, you must configure the server to accept certificates coming from the Business Services Server. See "Configuring Web Service Requests Between a WebLogic Server and a Business Services Server Deployed on Separate Machines" in the JD Edwards EnterpriseOne Mobile Applications Installation and Configuration Guide.

For a mobile applications deployment, Oracle recommends that you enable SSL for mobile applications, the Business Services Server, and the WebDAV Server. The WebDAV Server is required for deploying the JD Edwards EnterpriseOne Mobile Applications application. For more information, see the JD Edwards EnterpriseOne Mobile Applications Installation and Configuration Guide.

4.13 Connectors Security

Connectors are point-to-point, component-based interoperability models that enable third-party applications and JD Edwards EnterpriseOne to share logic and data. JD Edwards EnterpriseOne connector architecture includes Java, Dynamic Java, and Component Object Model (COM) connectors and provides access to JD Edwards EnterpriseOne business logic and data.

4.13.1 Secure Configuration Files

Java connector and COM connector use configuration files to connect to a JD Edwards EnterpriseOne environment. Secure JDBj.ini, interop.ini and JDELOG.PROPERTIES using operating system security.

Caution:

Implementing security on these files will prevent Server Manager from modifying configuration settings within these files.

4.13.2 Secure Log Files

You should give only certain users access to view connector log files (error and debug), as these files might contain sensitive information about the user and location of the database.

Refer to the JD Edwards EnterpriseOne Tools Connectors Guide for more information about connectors.

Caution:

: Implementing security on these files will prevent Server Manager from being able to display the logs.

4.14 Desktop Security

In the context of EnterpriseOne, a desktop is considered the working environment for end users when accessing EnterpriseOne from a Microsoft Windows client or web browser.

4.14.1 Disable Browser Cache Setting

A browser caches various pages and states in memory to increase performance. It may be necessary to disable these performance features on the browser for security reasons, especially for a kiosk environment.

Refer to the JD Edwards EnterpriseOne Tools HTML Server Reference guides in the JD Edwards EnterpriseOne Installation and Upgrade Documentation Library for information about configuring the browser to disable caching:

http://docs.oracle.com/cd/E24902_01/nav/reference.htm

4.14.2 Update Browser

Update the browser when new versions are released because they often include new security features. See document 745831.1 (JD Edwards EnterpriseOne Minimum Technical Requirements Reference) on My Oracle Support for more information about EnterpriseOne supported browsers:

https://support.oracle.com/epmos/faces/DocumentDisplay?id=745831.1

4.14.3 Turn Off Browser Autocomplete Setting

For kiosk machines, turn off the autocomplete setting for the browser. Although desirable for frequently accessed pages, this feature should be disabled for privacy and security reasons. Even for an intranet environment, do not enable the autocomplete setting to store passwords.

4.14.4 Set Policy for Unattended PC Sessions

You should create a corporate policy for handling unattended PC sessions. Users are recommended to use the password-locked screen savers feature on all PCs.

4.14.5 Turn Off Server BSFN Trace for Windows Client

Change the ServerLog setting to 0 in the [DEBUG] section of JDE.INI file so that the Windows client does not request the BSFN server logs from Call Object kernel. Refer to the JD Edwards EnterpriseOne Tools Server Manager Guide for more information about this setting.

4.15 Framebusting (Release 9.1 Update 2)

Framebusting is a way to prevent clickjacking, which occurs when a malicious web site pulls a page originating from another domain into a frame and overlays it with a counterfeit page, allowing only portions of the original, or clickjacked, page (for example, a button) to display. When users click the button, they in fact are clicking a button on the clickjacked page, causing unexpected results.

For example, say your application is a web-based application that resides in DomainA, and a web site in DomainB clickjacks your page by creating a page with an IFrame that points to a page in your web application at DomainA. When the two pages are combined, the page from DomainB covers most of your page in the IFrame, and exposes only a button on your page that deletes all records in your web application. Users, not realizing they are actually in the web application, may click the button and inadvertently delete all records.

Framebusting prevents clickjacking by using the following JavaScript to block the application's pages from running in frames:

top.location.href = location.href;

In Server Manager, you can configure Security settings for the EnterpriseOne HTML Server to prevent framebusting in EnterpriseOne. The settings include:

  • frameBustingForLogin

  • frameBustingForE1Menu

  • frameBustingForApp

The valid values for each setting are:

  • always. If the page is in an iframe, the page will take over the whole window.

  • differentDomain. (Default) If the page is in a iframe and the page and parent window are from different domain, the page will take over the whole window.

  • never. Even if a page is in a iframe, the page will never take over the whole window.

For more information about the configuration group settings for the EnterpriseOne HTML Server, see the "EnterpriseOne HTML Server" in the JD Edwards EnterpriseOne Tools Server Manager Guide.

If you configure your application to use framebusting by setting the parameter to always, then whenever a page tries to run in a frame, the JavaScript code is run to define the page as topmost, and the page is disallowed to run in the frame.

If your application needs to use frames, you can set the parameter value to differentDomain. This setting causes framebusting to occur only if the frame is in a page that originates from a different domain than your application. This is the default setting.

Note:

The origin of a page is defined using the domain name, application layer protocol, and in most browsers, TCP port of the HTML document running the script. Pages are considered to originate from the same domain if and only if all these values are exactly the same.

For example, say you have a page named DomainApage1 in your application that uses a frame to include the page DomainApage2. Say the external DomainBpage1 tries to clickjack the page DomainApage1. The result would be the following window hierarchy:

  • DomainBpage1

    DomainApage1

    DomainApage2

If the application has framebusting set to be differentDomain, then the framework walks the parent window hierarchy to determine whether any ancestor windows originate from a different domain. Because DoaminBpage1 originates from a different domain, the framebusting JavaScript code will run for the DomainApage1 page, causing it to become the top-level window. And because DomainApage2 originates from the same domain as DomainApage1, it will be allowed to run in the frame.