Security and PeopleSoft Enterprise

An Oracle White Paper

July 2006
 Security and PeopleSoft Enterprise

PeopleSoft Enterprise Approach to Security Services.................................................................... 2

Supporting Technology Infrastructure – PeopleSoft Enterprise and PeopleTools............... 2
Application Access Security ........................................................................................................... 2
Process Security ............................................................................................................................... 2
Object Security................................................................................................................................. 2
Application Data Security............................................................................................................... 2
PSQuery Security ............................................................................................................................. 2
Pluggable Cryptography.................................................................................................................. 3
Directory Server Integration .......................................................................................................... 3
PeopleSoft Enterprise Architecture Directory Server Integration ...................................... 4
PeopleSoft Enterprise Directory Interface .................................................................................. 4
Single Signon for PeopleSoft Enterprise...................................................................................... 5
Secure Sockets Layer (SSL) and Digital Certificates................................................................... 5
SSL for Secure Communications .................................................................................................. 5
Security and Web Services.............................................................................................................. 6
Decentralized Security Administration......................................................................................... 6
Browser-based Security Administration Tools............................................................................ 6
Enhanced Authentication—Signon PeopleCode................................................................... 6
Signon PeopleCode:.................................................................................................................... 6
Externalized Authentication, Single Signon, Certificate-based Authentication ..................... 7
Externalized Signon Process ..................................................................................................... 7
Additional Security Features...................................................................................................... 8
Securing Between Tiers................................................................................................................... 9
Encrypting Communications Between Tiers .......................................................................... 9
Securing the Application Server to Database Server Interface: ........................................... 9
Deploying PeopleSoft Enterprise Applications Securely Over the Internet .......................... 9
Securing Perimeter and Communications Channels.............................................................. 9
Firewall/DMZ configurations ................................................................................................10
Reverse Proxy Configuration (PeopleSoft Enterprise applications behind DMZ).........10
PeopleSoft Enterprise Web Server in DMZ.........................................................................11
Securing Communications Channels ..........................................................................................11
In Conclusion .....................................................................................................................................11
 Security and PeopleSoft Enterprise

PEOPLESOFT ENTERPRISE APPROACH TO SECURITY SERVICES

Security is of paramount concern to Information Technology organizations today. Protecting against computer criminals,
limiting the “insider threat,” and ensuring compliance with privacy, data breach, and financial accountability laws are now
top priorities for IT executives. Security features such as access control, user authentication, data encryption, and audit
support have therefore become important software buying criteria. Survey after survey shows that security is the number
one priority where new IT investment is planned.1

Supporting Technology Infrastructure – PeopleSoft Enterprise and PeopleTools

The PeopleTools environment provides the application development and runtime framework for Oracle’s PeopleSoft
Enterprise applications. It also provides the appropriate mechanisms to support native and enterprise security services.
PeopleTools also includes facilities to enable the use of external security tools and solutions. This provides a basis for
secure applications in an enterprise environment with the minimal development effort. In addition, this ensures that the
underlying PeopleTools technology is designed to provide effective enterprise security solutions.

Application Access Security

Security Administration is used to control navigational access to the PeopleSoft Enterprise applications that each user can
access based upon their role. Granting or restricting access to application components, the business transactions,
accomplishes this.

Process Security
The PeopleSoft Enterprise Process Scheduler is a background processing and scheduling facility. Process Scheduler can be
used to assign Process Definitions to various Process Groups and then grant or restrict user access to those groups using
Security Administration. If a process definition is not assigned to a user’s authorized process groups, the user does not
have permission to run that process.

Object Security
Object Security governs access to the individual metadata definitions for development purposes. Record definitions, Field
definitions, Page definitions, and others created with the Application Designer integrated development environment are
controlled with Object Security. This facility is used to protect specific object definitions from being modified by
developers. There is also an option to restrict access to entire object types.

Application Data Security

There are a number of ways to control the application data that a user can access in the PeopleSoft Enterprise
applications. Application data security provides data security at table level, row level, and field level.

Query Security
PSQuery is an ad hoc reporting tool used to generate SQL queries to retrieve information from application tables. Each
PSQuery user can be assigned access to specific tables for building and running queries. PSQuery Access Groups provide
data level access control at the table and column levels. Queries are created and then operators are assigned to those
groups using PSQuery Security. PSQuery Security is enforced only when using PSQuery - it does not control runtime page
access to table data.

1 Goldman Sachs, Independent Insight, US Technology Strategy IT Spending Survey, January 12, 2006
Row Security views are special types of SQL views that can be used to configure control access to individual rows of data
stored in the application database tables. PeopleSoft Enterprise applications come with built-in, row-level security
functions tailored to specific applications. For example, PeopleSoft Enterprise Human Capital Management includes
security tables that support the restriction of operator access to employee rows according to organizational roles or to
allow an operator to view and update rows only for employees in their department.
PeopleCode can restrict access to specific fields or columns within application tables. For example, if a certain user role
should be able to access only certain pages but not be able to view a specific field on those pages (e.g., compensation
rate), PeopleCode can be used to hide the field for that role.

Pluggable Cryptography
Pluggable encryption augments the existing support for encryption. This technology enables you to secure critical
PeopleSoft Enterprise application data and communicate securely with other businesses. It enables you to extend and
improve cryptographic support for data in PeopleTools. It also provides strong cryptography with the flexibility to change
and grow by incrementally acquiring stronger and more diverse algorithms for encrypting data.
Any data used in an application can be encrypted by invoking PeopleCode to apply your preferred encryption algorithms.
These algorithms from can be obtained from various vendors’ cryptographic libraries. The features of pluggable
cryptography include:
• Access to a robust set of algorithms (symmetric and asymmetric ciphers, password-based encryption, hashes,
media access controls, signatures, enveloping, encoding, and writing and processing secured messages).
• The ability to encrypt, decrypt, sign, and verify fields in a database.
• The ability to encrypt, decrypt, sign, and verify most external files.
• A secure keystore for encryption keys of widely varying types.
• The ability to convert data from one encryption scheme to another.
The functional elements of pluggable cryptography are:
• A dynamic link library (DLL) for each supported encryption library that uses C glue code to convert each
cryptographic library’s application programming interface (API) into a unified plug-in with an API accessible
from PeopleCode.
• A universal keystore that handles all forms of encryption keys, protected with row-level security.
• A sequence, or chain, of algorithms that you define for a specific encryption task. These algorithms are applied in
turn to transform data from its original form into a desired final form.

Directory Server Integration

Most enterprise application technologies utilize the concept of a user profile for authentication. Examples of this include
e-mail, collaborative applications, relational database systems, and network operating systems. In addition, the use of
directory servers based upon the Lightweight Directory Access Protocol (LDAP) has become commonplace.
Internet applications can provide access to a very large user audience. User profile creation and maintenance can be a large
bottleneck in rolling out Internet applications such as employee self-service.
Directory server integration addresses this issue by leveraging a central user profile repository, instead of duplicating user
profiles in the application system. PeopleSoft Enterprise authentication processing provide the option to seamlessly
integrate with the leading directory servers. This integration goes beyond authentication to include the bi-directional
maintenance of security attributes between the directory server and the authorization security in the application.
Figure 1: The PeopleSoft Enterprise Architecture

PeopleSoft Enterprise Architecture Directory Services Integration

Integrating PeopleSoft Enterprise user profiles with LDAP directories provides PeopleSoft Enterprise customers with the
following benefits:
• Customers can use a single, centralized user profile for PeopleSoft Enterprise applications and other Enterprise
applications. This results in lower maintenance costs and fewer errors because user attributes are not stored
redundantly.
• Customers can leverage PeopleSoft Enterprise business events and data to drive LDAP user profile and group
creation and maintenance. For example, when an employee is hired within the PeopleSoft Enterprise Human
Capital Management system, an event can be triggered within the PeopleSoft Enterprise application that results
in the creation of a user profile in the LDAP directory. The customer can then leverage this profile information
across all their enterprise applications.
Industry leading directory sever technologies have been certified with the PeopleTools architecture: Oracle Internet
Directory, Novell eDirectory, Sun ONE, and Microsoft Active Directory. The integration between the PeopleSoft
Enterprise architecture and the directory are written using native LDAP standards, therefore customers can essentially use
any LDAP version 3 compliant server. The implementation of LDAP is fully LDAP v3 compliant and supports use of
SSL (LDAPS) to secure the interface to the directory.
It should also be noted that PeopleSoft Enterprise applications use an open, extensible authentication API for directory
server integration. Other authentication schemes can easily leverage these same APIs. For example, PeopleSoft Enterprise
applications seamlessly integrate with PKI (Public Key Infrastructure) authentication services, third party single signon
solutions, or other services. For more information on integrating with other authentication mechanisms, see the
Enhanced Authentication—Signon PeopleCode section of this paper.

PeopleSoft Enterprise Directory Interface

Business events from Human Capital Management can be used to integrate with the directory server to maintain a user's
directory profile. The New Hire transaction in HCM is an example of this. This type of directory integration can leverage
employee events to trigger integration with the directory server. The PeopleSoft Enterprise Directory Interface product
was developed to provide this functionality. The PeopleSoft Enterprise Directory Interface is a separately licensed
application that provides integration and synchronization of employee data in PeopleSoft Enterprise HCM with the
directory server attribute information. The Integration Broker technology provided with PeopleTools manages the
integration between HCM and the directory server.
Customers can tailor the LDAP subscription processes to accommodate the schema that has been implemented in the
their directory. An LDAP mapping tool is provided that simplifies the mapping of data between the PeopleSoft
Enterprise applications and the LDAP directory.

Single Signon for PeopleSoft Enterprise

Many users of PeopleSoft Enterprise applications navigate between PeopleSoft Enterprise systems, depending upon their
daily tasks. For example, an Accounts Payable manager may review invoices in the PeopleSoft Enterprise Financials
system and then approve salary increases in the PeopleSoft Enterprise HRMS system. Users are not forced to sign on
multiple times to different PeopleSoft Enterprise systems and remember a long list of user IDs and passwords. Security in
PeopleTools directly addresses these issues. The directory server helps address the multiple user ID and password issue.
Since all PeopleSoft Enterprise applications can now authenticate against a single directory server, the user will only need
to remember a single user ID and password.
Some customers may choose not to implement directory server integration in PeopleSoft Enterprise. In this case, the user
IDs and passwords are stored in the PeopleSoft Enterprise system. For these customers, PeopleSoft Enterprise
Application Messaging is leveraged to automatically synchronize the user profiles across databases.
The PeopleSoft Enterprise architecture uses web browser cookies to store a unique access token for each user when they
are initially authenticated. When the user connects to another PeopleSoft Enterprise system, the token in the browser
cookie is used to re-authenticate the user so the use need not go through the signon process again. It should be noted that
the browser cookie is an in-memory, encrypted cookie in order to provide a secure environment for managing this
authentication.

Secure Sockets Layer (SSL) and Digital Certificates

PeopleTools security uses Hypertext Transfer Protocol over SSL (HTTPS) to secure the transmission of the content
delivered to and from a user’s browser. HTTPS is also leveraged by the Integration Broker for integration between
PeopleSoft Enterprise applications and other systems. Native SSL that is used to provide secure HTTPS communication
between the web browser and web server. All data transferred between the web browser and the web server is encrypted.
In addition, the authentication features of SSL can be used. See the section below on Enhanced Authentication—Signon
PeopleCode for more information on digital certificate based authentication.
Wherever systems communicate with each other across the web, data must be transmitted in a secure fashion.
PeopleTools security also leverages HTTPS and digital certificates for secure transmission of data between systems and
for system-to-system authentication. The SSL implementation for HTTPS is provided through the use of the
Entrust/Toolkit™ for Java™ that is embedded within PeopleTools. This requires no additional Entrust licensing by
PeopleSoft Enterprise customers and is designed for use with digital certificates provided by popular commercial
certificate authorities, such as Entrust and VeriSign, as well as internal certificate authorities.

SSL for Secure Communications

HTTPS not only provides for data encryption, but also provides mechanisms to ensure the source/destination of the
traffic is authentic by validating the digital certificate credentials of the sending/receiving system. In an HTTPS
connection, one system is the SSL Client and the other is the SSL Server. The initial SSL handshake ensures the server’s
digital certificate is valid. This is known as server authentication. Most web sites secured using SSL only use server
authentication. Optionally, the initial SSL handshake can also validate that the SSL Client’s digital certificate is valid. This
is known as SSL client authentication. This is also known as mutual authentication since both parties in the SSL
conversation authenticate each other. Authenticating both sides of the conversation is more secure as it helps ensure both
parties are whom they purport to be.
A number of security features are provided to secure communications using HTTPS. Both server authentication and the
optional mutual authentication are supported. Mutual authentication is more secure, but requires better Public Key
Infrastructure (PKI) coordination between systems, since compatible digital certificates are needed on the SSL server as
well as the SSL client. This is why most secure web sites that use SSL use server authentication, such as stock trading sites
and consumer retail sites. In order to support mutual authentication, these sites would require all user’s browsers have
compatible client certificates.

Security and Web Services

Web services are becoming prevalent as a method of discovering and integrating disparate applications. Web services
provide a standards-based method of easily exposing applications. These standards have been evolving and expanding
over the last several years. The PeopleSoft Enterprise architecture has supported web services for a number of years.
The first area of web services support is support for the Web Services Interoperability Basic Profile, which is emerging as
the specification for web service interoperability. This specification defines how protocols involved in web services are to
be used. This includes HTTP, Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), and
so on. In line with this standard, support is provided for WS-Security guidelines to ensure secure web services.

Decentralized Security Administration

PeopleSoft Enterprise applications can be accessed by thousands of internal and external users. This includes the
employees of the company as well as outside contacts such as customers and vendors. A centralized security solution,
where a single team of security architects must maintain all of the user profiles does not scale to support these types of
solutions. Customers need a way to decentralize security administration for their applications. The browser-based security
administration tools, built using PeopleTools, provide distributed security administration. Because these tools are browser-
based, they can be easily deployed to remote security administrators at a very low cost.
Using PeopleSoft Enterprise Security Administration tools, much of the security administration burden can be off-loaded
from the central security team. For example, a line manager of a company may use the distributed security administration
tools to set up user profiles for all employees in the department. Even a vendor company’s manager could create “vendor
contact” users for all of the employees within the vendor’s department that need access to PeopleSoft Enterprise
applications.

Browser-based Security Administration Tools

Enhanced Authentication—Signon PeopleCode

It is important to allow only authorized users to gain access to your system. Moreover, it is important to ensure that it is
indeed the authorized user that is accessing the systems, and not omeone using an authorized user’s credentials.
Authenticating users is an important aspect for internet security and the stronger the authentication mechanism the better.
Another authentication feature provided is Signon PeopleCode. Signon PeopleCode allows for authentication with many
different authentication mechanisms.

Signon PeopleCode:

When someone tries to login to PeopleSoft Enterprise, the signon process can be controlled through Signon PeopleCode.
Signon PeopleCode is PeopleCode that is triggered each time a user tries to login. The directory authentication feature
uses this Signon PeopleCode to invoke an LDAP integration process, but it is fully customizable. Some customers may
choose to use Unix security instead of LDAP. This can be done with minimal Signon PeopleCode. Perhaps a customer
wants to validate logins from internal IP addresses one way and external IP addresses in another, not an issue with with
Signon PeopleCode.
Strong authentication refers to methods beyond the basic User ID and Password pair most commonly used to access
application. Typically, strong authentication mechanisms employ two factor authentication where something the user has,
in his or her possession, and something the user knows is required to authenticate to the system. Examples of two-factor
authentication mechanisms include hardware tokens (e.g., in addition to a password, a physical device must be in
possession of the user to log on) and digital certificate based authentication (e.g., users authenticate to a Public Key
Infrastructure using their digital certificate and password or other additional authentication means).
A number of built-in features are provided to support various authentication means, including strong authentication.
These features are quite flexible, intended to enable PeopleSoft Enterprise applications to fit into the authentication
mechanism of most any security infrastructure. These features leverage built in facilities to support web server based
authentication and LDAP directory authentication. This is discussed in the next section.

Externalized Authentication, Single Signon, Certificate-based Authentication

PeopleSoft Enterprise has a variety of features to facilitate integrating PeopleSoft Enterprise into a third party security
solution for single signon/identity management or even for digital certificate based authentication to a Public Key
Infrastructure. For applications that have large user populations, such as employee or manager self service, it is sensible to
leverage a centralized mechanism to manage user accounts, identities and control authentication and access. In this way,
management of the user population applies to many applications, not just one application. Also, redundant user
identification data is minimized and the robust authentication features in these solutions can be leveraged across many
applications. Many of these 3rd party security solutions support strong authentication mechanisms including two-factor
authentication schemes, hardware tokens, smart cards, etc. By leveraging 3rd party security solutions with PeopleSoft
Enterprise, the authentication to PeopleSoft Enterprise using hardware tokens, smart cards and the like is achieved. The
key to PeopleSoft Enterprise’s ability to support such a wide variety of authentication mechanisms is the flexible design of
the signon process. The primary PeopleSoft Enterprise architectural elements involved include the PeopleSoft Enterprise
web server and Signon PeopleCode that executes on the PeopleSoft Enterprise application server. This signon process
using these elements is outlined in the diagram below.

Figure 2: Externalized Authentication

Externalized Signon Process

The externalized signon process largely involves the 3rd party system authenticating the user by whatever technique is
supported by the 3rd party system (e.g., digital certificate, user id/password, hardware token, smart card, biometric device,
etc.). When externalizing the authentication to PeopleSoft Enterprise to a 3rd party system, the PeopleSoft Enterprise
web server is configured to not present a separate PeopleSoft Enterprise login prompt. The steps in this externalized
signon processes are outlined below.
Externalized Signon Process flow:
1. The 3rd party system authenticates the user based upon user-entered input.
2. The 3rd party system passes the user’s ID (e.g., PeopleSoft Enterprise User ID, directory DN) to the PeopleSoft
Enterprise servlet.
3. The ID is passed to the signon PeopleCode on the application server.
4. When using a directory with PeopleSoft Enterprise, then PeopleSoft Enterprise obtains User Profile information
from the directory. If not using a directory, then the User Profile information is obtained from the PeopleSoft
Enterprise database.
5. Log the user onto the PeopleSoft Enterprise application with appropriate authorizations per the User Profile.
As illustrated, the externalized signon process enables PeopleSoft Enterprise to leverage the centralized authentication
services of a 3rd party solution, thus extending its inherent benefits into PeopleSoft Enterprise. As mentioned, this
process very flexible, deliberately designed to fit easily into many environments and architectures. Because the process is
implemented in signon PeopleCode, the countless virtues and capabilities within PeopleCode can be applied to the signon
and authentication/authorization logic.
To further illustrate this flexibility, the ID passed into PeopleSoft Enterprise in step 3 above need not be the actual
PeopleSoft Enterprise User ID. Out-of-the-box signon PeopleCode features for LDAP directory integration enable User
Profile information to be obtained from a directory. Thus, for many 3rd party authentication mechanisms the ID that is
passed into PeopleSoft Enterprise in step 3 is merely the authenticated user’s distinguished name (DN). The DN serves as
a pointer into the directory where PeopleSoft Enterprise User Profile information can be obtained, including the user’s
actual PeopleSoft Enterprise User ID. In this manner, it is very easy to use an email address as the PeopleSoft Enterprise
User ID. In this case, PeopleSoft Enterprise merely uses the contents of the mail attribute of the user object in the
directory as the PeopleSoft Enterprise User ID to log on to the PeopleSoft Enterprise application.
This flexibility and extensibility is very important in a collaborative enterprise since one application in your organization
cannot dictate or drive the security for the entire organization.

Additional Security Features

The following are several additional security features available to customers:

• Security Administrator. All user profile, role maintenance, and permission list pages are completely
PeopleTools based and deployed through a web browser. This means that the security functionality is full
customizable with the delivered integrated development environment. Need to add an additional field to a user's
profile? No problem! Need to publish an XML message to other systems when some aspect of security changes?
No problem! Need to tie workflow into security administration? No problem! Need to make a wizard style
interface for those line-level managers who are now maintaining the security? No problem!
• Security Administration is Completely API Accessible. Since Security Administration is built with
PeopleTools, it can easily be exposed to external security sources. You can create, update, PSQuery, and delete
any of the security information using web services, COM, C/C++, or Java.
• Rules-based Roles. PeopleSoft Enterprise security's rules-based roles allow customers to define the business
rules for who qualifies for what roles. The rules can be abstracted in PeopleSoft Enterprise Queries, PeopleCode,
LDAP rules, or even Java and C/C++. By providing rules-based roles, employees can automatically transition
roles as they are hired, transferred, or when they leave the company. The PeopleSoft Enterprise applications,
especially the portal solutions, can then provide the appropriate content to end users based on the roles for
which they qualify. The end result is that the roles are more powerful and dynamic and require less overall
maintenance when compared to static roles that are simply lists of end users.
Securing Between Tiers
In environments where the PeopleSoft Enterprise architecture elements are operating in non-secure areas, communication
paths between the tiers can be secured with encryption options. Using these encryption options, information and data
passing between the tiers are secure from eavesdropping. These encryption options are illustrated below.

Figure 3: Security Through PeopleSoft Tiers

Encrypting Communications Between Tiers

Securing the Web server to Application Server Interface: The communications interface between the PeopleSoft
Enterprise web server and application server is provided through the use of BEA Jolt middleware. Encrypting Jolt traffic
is a standard configuration option that includes support for strong encryption.

Securing the Application Server to Database Server Interface:

With its open architecture, the PeopleTools architecture supports the leading commercial database platforms. The
communications interface between the application server and the database server is provided through the use of the
database connection interfaces provided with each particular database. Most database connection interfaces provide
means to encrypt the connections to the database.

Deploying PeopleSoft Enterprise Applications Securely Over the Internet

Specific business requirements sometimes dictate that applications from outside the internal network connect over the
internet for collaboration. This enables customers, suppliers, partners, employees, consultants, and others to access
business processes from virtually anywhere in the world. With PeopleSoft Enterprise security, appropriate levels of
security safeguards can be readily employed in your PeopleSoft Enterprise implementations in order to realize the many
tremendous business benefits and minimize potential security risks. This section discusses some pragmatic approaches
towards adequately securing your PeopleSoft Enterprise applications over the internet and help provide appropriate access
while employing safeguards to minimize risk exposure. While there is no silver bullet, process or solution to guarantee a
secure system (there are essentially no secure systems, only systems with varying levels of security risk exposures) this
section cites real life examples, best practices, methods and techniques and identifies specific PeopleSoft Enterprise
security features to employ.

Securing Perimeter and Communications Channels

Deploying PeopleSoft Enterprise to be accessible from the internet requires a network infrastructure that limits direct
access to critical elements. In the PeopleSoft Enterprise architecture, the most critical elements of the architecture are the
PeopleSoft Enterprise Application Server and the PeopleSoft Enterprise database server. The web server is not as critical
because it does not employ business logic or access application data). It is important to note that since PeopleSoft
Enterprise applications all leverage the same PeopleTools architecture, the references to PeopleSoft Enterprise elements
apply in the same way to all PeopleSoft Enterprise applications such as Customer Relationship Management, PeopleSoft
Enterprise Portal solutions, Human Resources Management Systems, Financial, Supply Chain, etc.
The general method to limit direct access to critical elements is not unique to PeopleSoft Enterprise and employs two
firewalls. The outer firewall permits access from the internet while the inner firewall only permits access from that which
has already made it past the outer firewall. In this way, there is a somewhat safe-haven zone, commonly referred to as a
de-militarized zone or DMZ. Best practices strongly suggest the basic firewall and network configuration is well
established and tested before adding the PeopleSoft Enterprise elements into the network architecture.

Firewall/DMZ configurations

In deploying PeopleSoft Enterprise applications in a DMZ configuration the primary decision surrounds whether to place
the web server within the DMZ or behind it. There are of course many other potential combinations, but these primary
alternatives are discussed below. Both configurations are very secure and reasons to implement one over the other will
likely depend on specific characteristics of your network security topology and policies. In general though, the further
back behind firewalls the better, for placing PeopleSoft Enterprise elements in the network architecture.

Figure 4: Reverse Proxy Configuration

Reverse Proxy Configuration (PeopleSoft Enterprise applications behind DMZ)

The configuration employs a reverse proxy in the de-militarized zone. All PeopleSoft Enterprise elements, including the
PeopleSoft Enterprise web server are behind the inner most firewall.
A reverse proxy is simply a server (not part of PeopleSoft Enterprise) that employs two network interfaces, one to the
external internet and the other to the internal network. In this fashion, the reverse proxy protects the PeopleSoft
Enterprise environment by preventing any direct access to the PeopleSoft Enterprise web server from the external
internet. The reverse proxy forwards any HTTP(S) requests received from the outside on to the PeopleSoft Enterprise
web server. Similarly, any responses from the PeopleSoft Enterprise web server are forwarded back to the requestor
(browser or system).
One of the primary characteristics of this configuration above is its simplicity in terms of firewall configuration. The
firewalls need only be configured to allow standard traffic through, namely HTTP, or HTTPS if using Secure Sockets
Layer (SSL) on the PeopleSoft Enterprise web server. Another characteristic of this configuration is that even if the
Reverse Proxy in the DMZ is compromised, there’s essentially no PeopleSoft Enterprise information or data on it that
can be exploited.
The configuration with a reverse proxy in the DMZ providing access to PeopleSoft Enterprise elements behind the inner-
most firewall has been deployed successfully within internal PeopleSoft Enterprise implementations. In this manner, end
user browsers and systems accessing PeopleSoft Enterprise appear to be accessing the PeopleSoft Enterprise web server
directly from the internet, when in fact they are really only able to access the reverse proxy server. Moreover, no
noticeable degradation in performance has been detected using this type of configuration.
Figure 5: PeopleSoft Enterprise Web Server in DMZ

PeopleSoft Enterprise Web Server in DMZ

This configuration places the PeopleSoft Enterprise web server within the de-militarized zone; PeopleSoft Enterprise
Application Server and Database Server are behind the innermost firewall. In the above configuration, the PeopleSoft
Enterprise web server resides within the DMZ protected by the outer-most firewall. This configuration permits direct
external access to the PeopleSoft Enterprise web server while restricting direct access to the PeopleSoft Enterprise
application server.
The outer-most firewall need only be configured to allow standard traffic through, namely HTTP, or HTTPS if using
Secure Sockets Layer (SSL) on the PeopleSoft Enterprise web server. A unique characteristic to this configuration
surrounds the interface between the PeopleSoft Enterprise web server and application server.
The communication protocol between the PeopleSoft Enterprise web server and application server is provided through
the use of BEA Jolt middleware. When the PeopleSoft Enterprise web server resides in the DMZ, per Figure B above,
Jolt traffic needs to pass through a firewall. The innermost firewall then needs to be configured to allow the Jolt traffic
between the appropriate ports on the web server and application server. While configuring the firewall to allow Jolt traffic
is a simple, documented process, it is not generally as familiar to network administrators as configuring a firewall to allow
HTTP or HTTPS traffic.
Whether to choose a configuration with the PeopleSoft Enterprise web server behind the DMZ or within it is subject to
debate. Generally speaking, the further back the elements are located behind the outer perimeter the more secure the
system—at least from the external internet.
Having the web server within the DMZ can provide some performance gains as the web server is closer to the edge
perimeter but this comes with increased exposure as the web server is directly accessible from the internet.

Securing Communications Channels

In general, and especially when deploying PeopleSoft Enterprise over the Internet, any communications channel to or
from PeopleSoft Enterprise should be secured. This not only includes the end-user browser access but the
communications channels used for integration to external systems as well. As previously mentioned, since HTTP is the
primary transport mechanism used for integration SSL should be used to secure the integration communications channels.
For PeopleSoft Enterprise Portal, HTTPS enables content from secure remote web sites to be aggregated. For
Application
Messaging, HTTPS enables the XML-based Application Messages sent to, and received from, remote systems to be
transferred securely. Synchronous calls to external systems can be made over HTTPS. HTTP(S) was chosen as the
transport mechanism for these PeopleSoft Enterprise integration features so as to specifically facilitate integration in
secure internet environments such as the firewall/DMZ configurations noted above.

IN CONCLUSION
Security is of paramount concern to Information Technology organizations today. Protecting against computer criminals,
limiting the “insider threat,” and ensuring compliance with privacy, data breach, and financial accountability laws are now
top priorities for IT executives. Security features such as access control, user authentication, data encryption, and audit
support have therefore become important software buying criteria.
As demonstrated throughout this paper, PeopleTools provides the appropriate mechanisms to support native and
enterprise security services. Whether its authorizing end users, integrating with directory services or securing PeopleSoft
Enterprise applications for external access, PeopleTools offers robust mechanism to secure and protect your application
assets.
Security and PeopleSoft Enterprise
July 2006
Contributing Authors: Jim Ellis, Michael Seymour, John Heimann

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

Copyright © 2006, Oracle. All rights reserved.

This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft Enterprise, and Siebel are registered trademarks of Oracle
Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.