Hacking OneWorld â€“ a Security Document

erpSOURCING LLC - All Rights Reserved January 2002

Hacking OneWorld – a Security Document

Disclaimer

All information contained in this document should be treated as hypothetical. ErpSOURCING provides advice and informative views that are independent of JD Edwards through their various partners. All views and information contained herein may either be countered by JD Edwards documentation or may not apply to other customers or project plans. All information is therefore provided as a recommendation – and no information can be treated as a guarantee to project success nor as a guarantee against failure. All documentation contained herein is property of erpSOURCING LLC and is protected by Colorado laws.

None of the entries in this document are in any way a replacement for any JDEdwards OneWorld Xe documentation – and should be viewed as a complement to any existing documentation.

Technology Demographic Table Product OneWorld

Version Xe

Platform/OS All

Industry All

Application Technical, Security

Database All

Keywords OneWorld, CNC, Security

Date February, 2003

@ WORK SERIESHands-on OneWorld Information

-

erpSOURCING LLC - All Rights Reserved Page 2

Hacking OneWorld - a guide to setting up Security

Overview

This document is a comprehensive, customized guide to different aspects of OneWorld security and provides guidelines to an MIS department when assigning OneWorld security levels. OneWorld client security needs to be defined before “go live.”

In particular, this document discusses:

� Users and User Groups

� Security Checklist for Limiting Application Access

� NT File Security for the Deployment Server

� Specific Security Types, Including a Brief Discussion of Each

Assumptions

A number of assumptions are made in this document.

� No outside interfaces are being used to transfer data into any OneWorld tables and the client is not co-existent with World software.

� Security, as defined, would need to be fully tested in a client environment to ensure proper functionality and integrity.

� Security changes outside the scope of this document (such as extending security to encompass other geographic locations) might invalidate certain aspects of OneWorld security.

Introduction to OneWorld Security

Understanding how OneWorld handles security is crucial to understanding the options available to OneWorld security administrators. This document is to be treated as a compliment to the Configuration Planning and Setup guide – also known as the System Administration Guide..

Users and User Groups

Security Administrators use User IDs and User Groups to define security levels for individuals working in OneWorld. The Security Administrator can set up OneWorld security as follows:

� For individual users, you can use User IDs to control OneWorld security. Individual overrides and permissions can be granted to those who need special access in conjunction with or above the security allowed by any groups they are assigned to.

� For a group of individuals performing the same tasks, you can define Group IDs to control security for the group as a whole. Grouping of end-users eases administrative responsibilities and assigning of user security. Group definition is based on responsibilities, user functions, or is site specific. For example, all users in Purchasing can use the same Group ID (such as “Purchase”) and will have the same security applied.

� All users automatically fall under a global security category defined as *PUBLIC. When you use the *PUBLIC ID, assigned security is applied to all users; therefore, specific User IDs are not necessary.

-



OneWorld checks security in the sequence User ID ➜ Group ➜ *Public, except for Row Security. If the system does not find a specific entry for the User’s ID, it then looks for a Group entry and then for the *Public entry before any access is allowed.

OneWorld caches Security information from the Security Workbench table (F00950) in the client workstation’s memory when the user logs on. Security changes made by the Security Administrator do not immediately take effect for a user if he is logged on to OneWorld when the change is made. This particular user must sign off and then back on for the security changes to take effect at his workstation.

This document primarily focuses on defining security groups. Security considerations are indicated for eight groups. Group security levels are based on user responsibilities, user functions, or are site specific. Different groups have different levels of access to the various OneWorld components. These access levels and responsibilities are discussed in the document.

OneWorld Groups, Group Access Levels, and Group Responsibilities

This following schematic shows the eight different groups discussed in this document and how they access OneWorld Technical or Business data. Underlined descriptions are the defined OneWorld User Profiles. These profiles vary based on client and business needs and can be used as Group templates for your individual needs. Each group has its own set of needs and access levels. Users in a single group have access to the same environments, the same initial sign-on menu, and so on. Definition of OneWorld groups is similar to NT group definition, although in OneWorld one group cannot be part of another group.

-



The groups defined here are not all-inclusive and will vary based on client needs and business requirements. This discussion is only for clarification of group concepts and suggested guidelines. Customers should assess their own needs when determining what groups should be created.

In your enterprise, you can use some of the pre-defined OneWorld profiles for security and access to applications and other objects (e.g., Menus, UDCs, Data Dictionary, etc). The following table shows the OneWorld User Group IDs, and the corresponding Group Profiles discussed in this document:

OW User Group ID Corresponding Group Profiles PRODUSER Application User Group APPLEAD Application Super User Group CNCADMIN MIS/DB/OW Administrator, PVC DEVUSER Developer

Each group defined below is designated by a group number (1 through 8). These numbers are used in the third column of the Security Checklist for Limiting Access to Applications table following the definitions. All indications in this table are subject to change, as the actual requirements will be determined by the client.

(1) Application User Group – (PRODUSER)

� Definition – The Application User Group categorizes end-users based on a specific application (e.g., Purchasing, A/R, temps, Data Entry Clerks, etc.). This group has the tightest security level.

� Access Level – The Application User Group should only have access to either the OneWorld pre-defined menus or custom menus needed for their daily or routine tasks. A good way to set up security for this group is to only allow access to a custom initial menu and disable fast path. If access to additional programs is required, it can be granted by placing the additional programs on the custom menu.

(2) Application Super User Group – (APPLEAD)

� Definition – The Application Super User Group includes team leads or supervisors of specific Application groups (e.g., Purchasing Lead, A/R Lead, and so on). This group has fewer security restrictions than the Application User Group since team leads or supervisors need to perform certain setup and department level activities.

� Access Level – The Application Super User Group needs the same access level as the Application User Group as well as the ability to create new versions, move or copy versions between path codes, create new menus, and add new UDC values. For detailed access information, you should refer to the table at the end of this section.

-



(3) Workflow Administrator

� Definition – A Workflow Administrator is only applicable if using OneWorld® Workflow. The Workflow Administrator is responsible for maintaining the business’ Workflow process flow and continuity. These administrators ensure that all Workflow processes are running smoothly and without bottlenecks. This group is usually an Application Super User but with additional responsibilities and authority.

� Access Level – This role can be shared between various application team leads with one team lead responsible for all advanced analysis. Team leads can be responsible for Queue management and Group revisions. For metrics, a qualified person with knowledge of metric analysis should be used. You can refer to the Workflow Guide for more information.

(4) Data Dictionary/UDC/Menu Administrator

� Definition – The Data Dictionary/UDC/Menu Administrator is responsible for making changes to the Data Dictionary, UDCs, and OneWorld menus. If this person is already part of a group that lacks access to the DD/UDC/Menu applications, then specific-by-user profile access should be set up.

� Access Level – Application team leads can be responsible for this task, but we would recommend having a single person responsible for all changes. Data Dictionary replication has changed in B732. You should have have one Central Workstation for making DD changes. This cuts down on rebuilding DD tam specs because the administrator can drag and drop DDDICT and DDTEXT tam files onto the server.

(5) Third Party Report Writer

� Definition – Third Party Report Writers need to provide a USER ID and Password. This grants report access to all data (OneWorld row level and column security).

� Access Level – Report writers from outside your organization require specific User IDs. Since Report Writers need a USER ID, table security (row and column security) should be defined for that USER ID.

(6) PVC (Product Version Control) Group – (CNCADMIN)

� Definition – The PVC group works very closely with the development group to ensure timely Package builds and deployments of Updates and is responsible for keeping track of numerous objects and operations. These can include: Objects checked in and out by developers; Object transfer (moving objects between path codes); Package builds; Environment setup; Package Scheduling and Deployment (including 2nd tier deployment servers); Refreshing the Store & Forward MS Access database and the overall management of the Deployment Server directory structure; Global builds of Menu Word Search; the Object Cross Reference Facility; Deletion of Objects from the server; Rebuild of Business Function Documentation; Copying and movement of objects, such as, Media Object Queue content; Versions; Data Dictionary items; UDC tables; and Menus or any other SAR related object (objects or Business Data that would be needed by an application or a process on a SAR submitted by a developer).

� Access Level – Since the PVC group is responsible for package build, deployment, and Object Transfer, the bulk of the access to Technical programs is required. For detailed PVC Group access information, you should refer to the table at the end of this section.

(7) Developer – (DEVUSER)

� Definition – The Developer group is responsible for the creation of new Applications or modifications to existing applications.

-



� Access Level – Developers need special access to certain directories on the Deployment Server (Central Objects) for checking objects in and out. They also need all the OneWorld® programs necessary to modify and create applications. The table in the Deployment Server Directory Security section of this document outlines the access developers need on the deployment server (see the Development Users column).

(8) MIS/DB/OW Administrator – (CNCADMIN)

� Definition – The MIS/DB/OW Administrator is responsible for managing the servers (Services i.e. Security server, Transaction server, etc., Out-queues/Print jobs, INI file security, F98OWSEC table DB security), backups of the servers/data (Enterprise and Deployment), managing the databases, disaster recovery, printer setup, and general server/network maintenance. This person is also responsible for duties not performed by any other group.

� Access Level – The MIS/DB/OW Administrator needs access to the database, network, servers, and is responsible for all OW related technical responsibilities. This administrator needs access to all OneWorld programs along with full database access to all tables. This group also has network administrator, root authority, and QSECOFR authority (AS400).

-



Table Outlining Group Access

When determining group security levels, administrators should know which groups should not have access to particular technical programs. The following table indicates the groups by their assigned numbers.

Security Checklist for Limiting Access to Applications Technical Application Name Program Do Not Permit Access

Network Monitor 1 N/A 1,2,3,4 Universal Table Browser 1 N/A 1,2,3,4 All *.exe programs under System on the deployment server 1

N/A 1,2,3,4

UDC P0004A 1,3,6 Host Configuration P00053 1,2,3,4,6 Menu Design P0082 1,3,6 User Profiles P0092 1,2,3,4,6 Work with Environments P0094 1,2,3,4,6 Release master P00945 1,2,3,4,6 Security Workbench P00950 1,2,3,4,6 Machine Identification P00960 1,2,3,4 Queue Properties P01133P 1,2 2,4,6 Queue Security P01135 1,2 2,4,6 Work with Queues P012501 1,2 2,4,6 Group Revisions P02150 1,2 2,4,6 Start Escalation Monitor P9000020 1,2,4,6 Data Dictionary P92001 1,2,3,6 Error Messages P92002 1,2,6 Cross Reference P980011 1,2 Business Function where used P980012 1,2,3,4,6 Path Code master P980042 1,2,3,4,6 Batch Versions P98305 3,4,6 Interactive versions P983051 1,3,4,6 PO Text Translation P98306 1,2,3,4 Installation Planner P9840 1,2,3,4,6 Table Conversion/Merge log P984052 1,2,3,4,6 Installation Workbench P9841 1,2,3,4,6 Table Conversion Scheduler P98430 1,2,3,4,6 Object Librarian P9860 1,2 Promotion Manager P98603 1,2,3,4 Object Transfer P98604 1,2,3,4 OCM P986110 1,3,4 Data Sources P986115 1,3,4 Work with Servers P986116 3,4 Build Debug Info P98615 1,2,3,4,6 Server Package Installs P986150 1,2,3,4 B733 Printer Application P98616 1,2,3,4,6 Record Copy P9864 1 Process Master P98800 1,2,3,4,6 Checkout Log P9882 1,2,3,4 Work with Packages P9885 1,2,3,4 Process Activity Monitor P98860 1,2 2,4,6 Advanced Analysis P98870 1,2 2,4,6 Spec Merge logging Info P98881 1,2,3,4,6

-



Security Checklist for Limiting Access to Applications Technical Application Name Program Do Not Permit Access

Translation P988830 1,2,3,4,6 Deployment Locations P9889 1,2,3,4 Optional Tables Workbench P98920 1,2,3,4,6 User Overrides P98950 1,3,4,6 Business Function Documentation P98ABSFN 1,2,3,4 Data replication P98DREP 1,2,4,6 Media Object Queues P98MOQUE 1,2,3,4,6 User Security P98OWSEC 1,2,3,4,6 JDE Licensing Security P98SRV 1,2,3,4,6 Media Object Templates P98TMPL 1,3,4,6 System Control P99410 1,2,3,4,6 Workflow Data Consolidation PH9001 1,2 2,4,6 Create User Profiles from Address Book records

R0092 1,2,3,4,6

Summarize group profile information R00921 1,2,3,4,6 Create Publisher and Subscriber records

R00960 1,2,3,4,6

Purge Completed Tasks R01131P 1,2 2,3,4,6 Update display decimals R9200100 1,2,3,6 Replicate Data Dictionary Changes R92001T 1,2,3 Recreate Replicated Data Dictionary R92TAM 1,2,3 Installation Planner report R9840A 1,2,3,4,6 Plan validation R9840B 1,2,3,4,6 Installation Plan Copy R9840C 1,2,3,4,6 OCM mapping comparison R986101 1,2,3,4,6 Data Source master report R98611 1,2,3,4,6 OCM global update R986110 1,2,3,4,6 Data Source master comparison R986112 1,2,3,4,6 Verify OCM R9861130 1,2,3,4,6 Object Configuration delete R986120 1,2,3,4,6 Object Configuration copy R986121 1,2,3,4,6 Check out and Purge report R9882000 1,2,3,4,6 Process Activity Print R98860 1,2,3,4,6 Purge Completed Processes R98860P 1,2,3,4,6 Multi–tier package deployment R98892B 1,2,3,4 Generate Business Function Documentation

R98ABSFN 1,2,3,4

1 = Place NT security on these files when they reside on the deployment server. On the client workstation, the security for these programs can be controlled in Windows NT by limiting access for those executables on the deployment server. Grant permission only to certain users in NT for Read/Write or Execute permission.

2 = This responsibility can be assigned to each Application lead instead of a designated Workflow Administrator.

-



Deployment Server Directory Security

The following NT security types should be placed on the deployment server directories using NT security:

Directory

CNC Administrators(CNCADMIN)

(8)

Production Users

(PRODUSER) (1)

Development Users

(DEVUSER) (7)

Application Super User

Groups (APPLEAD)

(2) client

jdeclnt.ddc jdeclnt.xdc odbcdatasource.inf all other files

Read/Write Read/Write Read/Write Read/Write

Read/Write Read/Write Read/Write Read Only



pathcode /package all other subdirectories

Read/Write Read/Write

Read/Write Read Only



Database Read/Write No Access No Access No Access Datadictionary Read/Write No Access No Access Read/Write Helps Read/Write Read Only Read Only Read Only Hosts Read/Write No Access No Access No Access Mediaobj Read/Write Read Only Read Only Read/Write Planner Read/Write No Access No Access No Access Printqueue Read/Write No Access No Access No Access System Read/Write Read Only Read Only Read Only

Security Types and Considerations

The following sections discuss various security types you can apply in OneWorld. Each security type is discussed briefly, including suggestions on implementation where applicable.

Cost Center Security

Cost center security is implemented using OneWorld Row Security. This security type allows access to certain Cost Center records. This also applies when using the Universal Table Browser program.

Currently, OneWorld Row Security implementation does not combine the Group Profile security with User security. User security overrides Group security completely. You should refer to the Configuration Planning & Setup Guide for details on implementing Row Security.

-



Row Level Security for Specific Records

Row Level Security is exactly the same as Cost Center Security and prevents access to particular records in a database. The setup is the same as with Cost Center Security. Caution should be used when configuring row security because of the performance issues that are created if the wrong approach is used.

Form Level Security for Interactive Applications

Form Level Security should be implemented when you need to limit particular user or group access to part of an application. This decision is made by the Application team lead. This is similar to Application level security except it is more form specific. Refer to the Configuration Planning and Setup guide for more details.

Security Workbench (P00950)

You need to limit access to the Security Workbench (mentioned previously in the Security Checklist Table) so only one or two individuals have access to it. All changes should be routed through these individuals. This will typically be either an Application Team Lead or an MIS/DB/OW Administrator. As a word of caution, make sure the group does not secure itself out of the program.

Menu Security

Menu security limits access of end-users to specific, usually custom menus. This is accomplished by specifying opening menu for the group in the User Profile Revisions program. At this point, the administrator has the flexibility to allow Fast Path access to other menus. Fast Path is typically allowed for application team leads, but should not be available to end users.

UDC/Menu/Data Dictionary Security

Most application team leads should have access to UDC’s and Menu revisions, while most users should not. For Data Dictionary, the DD administrator should be the only one making changes.

Solution Explorer Security

Most groups should be allowed access to solution explorer configurations. You can grant permissions to allow certain users to perform their jobs with various features such as Internet, fine cut, fast path, rough cut and universal director.

Portal Security

Most users should not be allowed to access to the portal personalization forms. Portal relationships should defined by the system administrator. The system administrator can delete portal components from the system.

Scroll to Bottom on a Grid Security

Most groups should not have access to Scroll to Bottom on a Grid because this type of scrolling can significantly affect performance. Access should only be granted on a need-be basis to individuals or groups.

-



Media Objects Security (Adding or Changing)

Media Object security is set up at application design time. This allows for Viewing of Media Objects only, or for Viewing and Editing Media Object attachments. Security for Media Objects currently allows any user to change or delete a Media Object, if the application allows them to.

Processing Option Security

Processing Option security is typically set up for end-user groups who are only allowed a pre-defined set of Processing Options for a given application. You can allow view, change, or no prompting to the end user group.

Object Level versus Version Level Security

For Processing Option security, there is one overlapping area between Object Level security and Version Level security. Object Level security covers some of the functions of Version Level security, but in different ways.

� Object Level “Update” allows an unsecured user to view Processing Option values for any object version. Version Level security does not have an equivalent function.

� Object Level “Prompt for Values” bars unsecured users from viewing any Processing Option values for any object version. Except for the owner, Version Level security greater than zero bars all users from viewing the Processing Option values.

� Object Level “Prompt for Versions” security bars unsecured users from viewing any Oexplore or batch versions for an object. Version Level security always allows users to view all versions. However, except for the owner, a version security level of 2 (the highest) bars all users from doing anything with the version.

Workflow Security

Workflow Security should be enabled for customers implementing Workflow when automating their business processes. Since Workflow now automates the business processes (such as PO Approval routing), it is imperative to place security on those processes. All Workflow and Composer related programs are included in the technical tables list.

A Workflow administrator or Application Lead should monitor Workflow Queues and processes and ensure that Workflow related tasks are delegated to the appropriate staff. This administrator can also perform metrics (advanced analysis) on data created by previous processes. Application and queue security should be placed on the appropriate programs. You can refer to the Workflow guide for more information.

Using NT Defined Groups Names for your OneWorld Group Names

For ease of maintenance, you can use existing NT Group Names for your OneWorld Groups. This allows you to easily place security on the deployment server NT file structure objects and also reduces administrative overhead.

Deletion of Objects from Central Objects

During the development cycle, an object that is created and checked into Central Objects can only be deleted from the server Central Objects by specifying a J.D. Edwards supplied password. You can obtain this password by calling Response Line.

-



SQL *Net Security

SQL query tools can easily provide access to and be harmful to confidential business data. In order to avoid these costly errors, you should limit user access to the Query Tool. More importantly, the OneWorld database password should not be made available to anyone except the MIS/DB/OW Administrator. Because the database password is stored in the server JDE.INI file, it is important to limit access to the JDE.INI file.

Security and the JDE.INI File

For B733 and higher releases, users cannot bypass the security server by commenting out the JDE.INI “SecurityServer=” line if security server is turned ON (made Mandatory) through the P98OWSEC application. However, if the security server is turned OFF (not Mandatory) in the P98OWSEC application, users may comment out the Security stanza in the JDE.INI on their desktop and bypass the security server. The only limitation to commenting out the security section in the client JDE.INI is that the user should have a valid USER ID and password for all the databases being accessed via OneWorld.

Server INI File Security

As previously mentioned, the server JDE.INI file contains the database USER ID and password. Therefore, this file needs to be secured using NTFS security, Unix object security, or AS/400 object security.

JITI Security

In B733, JITI can be disabled for environments to prevent users from accessing applications that were not part of the original Lite Package. However, you should be careful since this also disables Versions JITI and consequently will not allow version specs to be JITI’d down if they do not exist on the client.

Workgroup Server Security

Workgroup servers use the same security as the deployment server. Replicated databases need to be secured and use of SQL query tools needs to be restricted.

Database Security on the F98OWSEC

The F98OWSEC table contains the OneWorld and database USER IDs and password. Only the MIS/DB/OW Administrator should have access to this table. No one should be locked out using native database security. To further secure your database there are five areas that should be given consideration: Access controls, remote access, integrity and availability, auditing, logging and monitoring, and authentication, identification and account management. Refer to your in-house security policies when implementing database security using these five areas as your guideline.

-



Having Multiple Copies of the F98OWSEC

When you have multiple security servers, you must also have multiple copies of the F98OWSEC table. You can create multiple copies using native database replication (if allowed), or using OW replication. If you do replicate this table, make sure that the replicated copy uses native database security as well.

BSFN Security

Business Functions need to be kept secure, especially in high development environments requiring some form of version control. Checking in and out can be controlled by only granting NT security to the development group for the deployment server directory structure.

Spec Security Spec files are environment files, and access to them should only be limited to the OneWorld kernel processes. Permissions on these files should be read-write only for the user and the group and should not be classified as executables. For platform specific information refer to the Configuration Planning and Setup guide.

INI File Security

Since the INI file contains the database password, access should be restricted to all except the USER ID or group returned from the Security Server. If security server is not running, then all users would need access to the INI file on the server to run.

UBE Security

Starting and Stopping OneWorld Security

Only certain users should be given authority to start and stop OneWorld processes because this authority also requires access to the INI file, which contains the database password.

-



OneWorld Web Security - Background

Threats to information systems can arise from a number of different directions and can attack a number of different components. The highly preferred method of applying security to a system involves implementing layered security, or security in depth. Three major categories of a system that require protection include databases, applications, and Web servers. This is illustrated for a generalized implementation in Figure One.

For a OneWorld implementation based upon this configuration,

� Database security would be implemented by proper installation and configuration of the database.

� System security would be applied through the use of proper system configuration, administrative practices, monitoring, and appropriate security tools.

� Application security for OneWorld would be implemented and managed with the native security tools provided with the product. This would include proper configuration of the security server, group and user permissions, object security, row and/or column security, etc.

OneWorld Web Architecture

Web-enablement of OneWorld requires a set of components supplied by the OneWorld Java Application Server (JAS). The middleware components comprising the OneWorld JAS allow access to OneWorld from a Web browser and make available the following functionality:

� OneWorld forms can be served to users via HTML or as Java applets

-



� Business functions and batch applications can be called

� OneWorld administrative operations (including security options and user profile management) can be performed

The architecture for a generic OneWorld HTML/Java-based implementation is shown in Figure Two.

The Java Application Server executes OneWorld interactive applications as server-side Java Class servlets and presents the output to the web client as HTML pages. JAS also serves OneWorld interactive applications as client side applets to a Java client. JAS facilitates business function and batch application calls to the Enterprise Server (or application server) via the JDENET messaging middleware component of OneWorld. The JDENET middleware provides communication between the JAS server (Intel® NT-based) and other servers (multi-platform) in the OneWorld implementation.

-



The JAS requirements for Web servers and Java servlet loaders by platform are defined in Figure Three.

Release v1.1 of JAS requires IBM WebSphere v3.02 as the servlet loader for all supported platforms. As a result of this, Microsoft® IIS v4.0 is the only Web server supported for this release in a Microsoft NT environment. Starting with OneWorld Service Pack 14.x, IBM WebSphere 3.5 is supported. For implementations running at this level, Microsoft IIS v5 can now be used. For AS/400® and UNIX® platforms, the currently supported Web server is the IBM HTTP Web server.

The JAS components constitute a technology layer between the infrastructure (i.e., Web server) and the web-enabled application (i.e., OneWorld interface). It is the infrastructure layer that is primarily exposed to security threats and hence the Web server is positioned to provide the primary security for the implementation. Proper configuration of the Web server (and it’s supporting hardware infrastructure) is an absolute requirement for a secure solution in this type of environment.

Web Server Security Recommendations

As mentioned previously, Web Server security provides the primary protection against Internet/Intranet based threats. This requires the proper configuration of the infrastructure components: system hardware/software, Web server, and Java servlet loader. The goal is to ensure that the key security elements (access control, authentication, integrity, privacy, confidentiality, and non-repudiation) are effectively implemented at the appropriate level relative to business needs.

Implementation of the SSL protocol and digital certificates represents the current best practice in providing secure communication across the Internet and private networks (including Intranets and Extranets). Application of these technologies, along with proper configuration of the Web server infrastructure, provides the following:

� Access control to the Web server components (via system configuration and SSL)

� Authentication between client and server (via digital certificates)

� Data integrity (via digital certificates)

� Privacy and confidentiality (via encryption)

SSL provides industry standard encryption technology that is widely used to protect sensitive information transmitted across Internet or secure intranet systems. SSL-enabled servers

-



encrypt the information to be transmitted before sending it across the public network, thus reducing the risk of information access should the transmission be intercepted. Furthermore, use of this protocol on a Web server facilitates authentication between clients and server-based resources.

It is an accepted best practice to use the strongest encryption (i.e., largest session key strength) required for the nature of the transactions being executed and consistent with technical and legal constraints. Note that application of encrypted communications requires that the Web server and any Web browser client both support the chosen encryption scheme (including encryption strength).

SSL-Based Communications and HTTPS Protocol

SSL-based communications use the HTTPS protocol. This is a hybrid protocol combining SSL with HTML to implement the encryption used to secure the message traffic. HTTPS requires use of port 443 on the Web server while HTTP uses port 80. As a result, both secure (SSL-based) and non-secure (no SSL) requests can be serviced simultaneously. This allows application of security only to those transactions that require it, thus reducing the impact of the overhead incurred for SSL-based operations. It is highly recommended that security policies align closely with business practices, threat assessment, and overall risk management in order to properly balance security and functionality. In highly secure environments, consideration should also be given to emerging technologies and products designed to speed up SSL-intensive operations.

Key Pairs and Encryption

SSL technology requires that the server maintain a pair of keys (public plus private) for the encryption system. The overall security of the SSL-based communications depends on maintaining control over access to and distribution of this key pair. To provide effective security, the loss of a key pair should result in the revocation of the corresponding digital certificate associated with the keys. However, depending on the established security policy and practices, consideration should also be given to creating a backup copy of the key pair and storing it in a safe place to facilitate administrative and maintenance tasks.

Although a key pair can be generated for a remote Web server (i.e., a Web server on a remote LAN or WAN segment), this is NOT a recommended practice. The key pair for a remote server must not be transmitted over an unsecured network if secure SSL communications are to be maintained.

The Web server uses digital certificates to send its public key to clients so that the client can authenticate signed messages from the server. An individual company can issue its own digital certificates (i.e., self-signed certificates), or the certificates can be obtained from an external certification authority (CA). Self-issued certificates are a reasonable choice for Intranet-based or some extranet applications where levels of trust are implicitly provided by close association with the company. However, the best practice for Internet-based commerce requiring establishment of trust with a diverse client base is to obtain certificates from a trusted certification authority.

Digital Certificates

The certification authority (CA) is typically a trusted third party (although it can be an authority within the company in the case of self-issued certificates). Whether internal or external in nature, the certification authority verifies the identity of the server(s) issuing digital certificates and validates the certificates in accordance with the processes applicable under the relevant certification practice statement. This ultimately facilitates authentication of the digital

-



certificates issued by that server. A signed digital certificate from a certification authority is required to enable secure SSL communications with a Web server.

The following should be considered when deciding what type of server certificate to implement:

� A self-issued certificate (e.g., issued via Microsoft Certificate Server or IBM’s IKEYMAN utility) allows the organization greater flexibility in implementing certificate issuance policies. This can be advantageous in matching certificate settings with overall company security policies, but does induce potentially significant administrative overhead.

� A cost analysis should be used to compare the overall cost of self-issued certificates with the overall cost of purchased certificates - substantial costs can be associated with obtaining a server certificate, especially if a high degree of identification assurance is required. Total costs would include both initial implementation costs and on-going administration costs. Training costs associated with initial implementation and on-going administration should also be evaluated.

� The type of certification practice that is required for the business operations must be considered. The certification practice involves the policies and procedures used by a certificate authority to establish and maintain trust-worthy operations. If a certificate authority is to effectively support global or cross-regional applications, it must be widely recognized and trusted by the customer base.

� An assessment of the degree of compatibility between the organization’s business practices and the certificate authority’s operations and product should be made. Some certificate authority services and products may not integrate well with existing security models and directory services. It should also be determined whether there are opportunities to leverage the technical, legal, and business expertise of the certificate authority.

� A determination of whether or not the information required by the certificate authority to provide identity verification is in alignment with business goals and company practices is important.

� An evaluation of whether the candidate certificate authority provides systems and infrastructure capable of receiving and/or processing certificate requests on-line should be conducted. This capability will often improve the speed of responding to certificate requests.

Following establishment of a digital certificate, the web server(s) and clients can be configured to recognize and utilize the SSL protocol. As with creation and management of a digital certificate, the details of configuring SSL depend on the particular infrastructure utilized and the business needs to be addressed. Although the generic steps for Microsoft and IBM web servers are provided in appendices, the reader is referred to the manufacturer information cited in the references section for detailed instructions for their particular platform.

-



Implementing Stricter Oracle Security for a OneWorld Database This chapter outlines a method and presents guidelines for implementing a security configuration on a OneWorld-Oracle database. After an install of OneWorld is completed using Oracle as a database, the data tables are accessible by any Oracle user who is a member of the instance. Thanks to the use of the security server functionality of OneWorld, the number of Oracle users needed for accessing the data is extremely small. It is much better to limit access to the OneWorld tables to those users only.

After outlining a general approach, PL/SQL scripts are provided as a starting point for implementing the desired security structure.

Overview Clients frequently need to use third party applications to access OneWorld data (e.g., data warehousing, in-house applications and ODBC connections to spreadsheets). If these needs cannot be addressed by the use of API calls or the JDE Direct access ODBC driver, then a user account in Oracle must be created in order to get access to the data. Unfortunately in a standard OneWorld install, that user will then have access to all OneWorld tables, with the concomitant risk of data corruption and access to sensitive data. By using the methods in this document, only a select subset of OneWorld-Oracle users used by the security server process will have access to the OneWorld tables. Access to specific tables and access modes can then be granted to the Oracle users required by third-party applications.

Oracle Privileges Oracle object security is controlled by object privileges, which are defined in the table below:

Privilege Allows Select Retrieve data from a table Insert Insert a new row into a table

Update Change a row in a table Delete Delete a row in a table Index Create an index on a table

Reference Allows the alteration of a table to create a Foreign Key Alter Allows alteration of the structure of the table

Execute Permits the execution of stored procedures and functions

These privileges can be granted to Oracle users or roles on a specific table or column of a specific table. For example this SQL statement:

GRANT SELECT ON FRED.MYTABLE TO BERT;

Would allow the user Bert to perform select queries on the table MYTABLE, which belongs to Fred. To grant all Oracle users access to the tables, the user name is set to PUBLIC. To grant every privilege on an object, then the keyword ALL can be used. Thus to grant all users every privilege on Fred’s MYTABLE, the following statement would be issued:

GRANT ALL ON FRED.MYTABLE TO PUBLIC;

At the end of an install the database is configured so that all Oracle user profiles are granted all object privileges to all OneWorld tables. This means that any valid Oracle user can perform any of the above actions on any table. This document presents a security design and scripts for removing the public grants to OneWorld tables, and assigns access to a limited number of

-



Oracle roles that can then be granted to the Oracle users require access for OneWorld to work successfully.

Three Levels of Implementation

The methodology consists of three levels of implementation. Each of these is discussed in more detail in the following sections.

� Level One should be adequate for most clients.

� Level Two is available for clients with highly sensitive data who want to go beyond the security built into the OneWorld security model.

� Level Three is a possible solution for clients with very complex security needs and who have the resources necessary to implement and test such a solution.

Level 1

Level 1 restricts access to OneWorld tables to two roles: JDE_SUID and JDE_ARIN. This revokes the public grants. If third party applications require access to a few specific tables then the Oracle users can be granted the appropriate privileges on the those tables. OneWorld’s own security system is used to control OneWorld users. The scripts will accomplish the revoking and granting on the OneWorld tables but you must modify them so that only the environments you wish to be secured are affected.

The procedure in Level 1 will remove the public grants, creates two new roles JDE_SUID and JDE_ARIN, and then assigns these new roles access rights to the OneWorld tables. You can then grant these roles to the selected OneWorld-Oracle users that need access to the database, for example the users specified as the system user in the security server configuration.

The JDE_SUID role is granted: Select, Update, Insert and Delete privileges to all the OneWorld tables. This role should be granted to the Oracle profile used as the system user for regular OneWorld user profiles.

The JDE_ARIn role is granted: Alter, Reference and Index.

Before running the scripts the GrantSUIDtoJDE_SUID.bat and the GrantARINtoJDE_ARIN.bat files must be edited so the CONNECT_STRING parameter is changed to the correct connect string for your database instances.

The scripts used to complete the process are outlined below.

The CREATE_NEW_ROLES.BAT batch file calls CREATE_NEW_ROLES.SQL, which create the two roles JDE_SUID and JDE_ARIn.

1. The first step in the methodology is to revoke all the public access to grants to the OneWorld tables. This is achieved through use of the batch file UNDO_ALL_PUBLIC.BAT. The batch file repeatedly calls a file UNDO_GRANTS.BAT which in turn calls Sql*Plus and executes a PL/SQL script called UNDO_GRANTS.SQL. You must comment out the appropriate lines in UNDO_ALL_PUBLIC.BAT for which you do not want this security model activated.

2. The second step grants: Select, Update, Delete and Insert to the JDE_SUID role. The batch file that accomplishes this task is called GrantSUIDtoJDE_SUID.bat, which calls the GrantSUID.bat file for each OneWorld Oracle schema. GrantSUID.bat calls Sql*Plus and executes a PL/SQL script called GrantPrivs.SQL You must comment

-



out the appropriate lines in GrantSUIDtoJDE_SUID.bat for which you do not want this security model activated.

3. For OneWorld users who need: Alter, Index and Reference privileges, i.e., users who will be creating new tables and indexes through the appropriate OneWorld applications, you will need to repeat the process with the GrantARINtoJDE_ARIN.bat script.

4. Once the scripts have been completed, you can grant JDE_SUID and JDE_ARIN to the appropriate Oracle users that are being used as system users for OneWorld user profiles. The simplest way of granting the JDE_SUID role to all the predefined Oracle users created during the OneWorld install is to grant JDE_SUID to JDE_ROLE.

Example of Granting Privileges to a Third Party Program

If a third party needs access to OneWorld tables then you may grant access to the files needed with appropriate SQL commands. For example to grant ‘READ ONLY’ access to the production address book table then you would issue the following statement at a SQL prompt:

GRANT SELECT ON PRODDTA.F101 TO EXCEL_USER;

Where EXCEL_USER is the name of the Oracle profile that will be used by the third party application.

If you need to grant more wide ranging access it should be a simple matter to modify the scripts as needed.

Level 2

Level 2 is for clients who wish to create additional Oracle security on a small set of tables that contain highly sensitive data. Level 2 is for clients who would like to ensure that only the minimum number of Oracle profiles have access to highly sensitive data (e.g., tables with payroll information).

• First a list of tables that need to be secured must be generated. The JDE_SUID role then has its privileges revoked on those tables.

• Next, create a role for accessing those tables and an Oracle profile that will be used as the system user for the OneWorld profiles of the users that need access to the sensitive data.

• Grant privileges to the sensitive tables to the new role.

• Grant the new role and JDE_SUID to the new Oracle user.

• Test all the relevant applications.

Level 3

Level 3 would use the same procedure as Level 2 but grant access at a column level on tables that contain both sensitive data and data which is required by all users. Naturally this level would require substantial research and testing.

-



Contact

For additional information contact:

Jon Steel Xe Upgrade Specialist erpSOURCING LLC�

Work phone : (904) 287 0021Cell phone : (904) 382 5701Fax Phone : (509) 756 4152Email (main) : [email protected] Number : 111747507

�

Documents

Hacking OneWorld â€“ a Security Document