Configuring Ps 8 Portal v1

Configuring a PeopleSoft 8 Portal
Contains:
Portal Roadmap Configuration Instructions Troubleshooting Tips Prepared by: Michael Hillerman
Configuring a PeopleSoft 8 Portal

December 24, 2001
Comments on this document can be submitted to redpaper@peoplesoft.com. We encourage you provide feedback on this Red Paper and will ensure that it is updated based on feedback received. When you send information to PeopleSoft, you grant PeopleSoft a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. This material has not been submitted to any formal PeopleSoft test and is published AS IS. It has not been the subject of rigorous review. PeopleSoft assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends upon the customer's ability to evaluate and integrate them into the customers operational environment.
Table of Contents
TABLE OF CONTENTS CHAPTER 1 - INTRODUCTION Structure of this Red Paper Related Materials CHAPTER 2 PORTAL ROADMAP Introduction Configure the network and server environment Configure the Portal Configure Security Define Users Define Content Customize the look and feel of the portal CHAPTER 3 CONFIGURATION OPTIONS Load Balancing Configuring a portal running under SSL to use HTTP connections to PIA on the same server. Using an SSL Accelerator Using a reverse proxy server Configuring the portal to use a proxy server to access the Internet. CHAPTER 4 - SESSION COOKIES Weblogic session cookie settings. Apache/JServ session cookie settings. CHAPTER 5 PORTAL CONTENT PROVIDERS Configuring the portal content providers CHAPTER 6 CONFIGURATION PROPERTIES FOR THE PORTAL AuthTokenDomain PortalUseHttpForSameServer DefaultScheme DefaultPort
3 6 6 6 7 7 7 7 8 9 9 10 11 11 16 18 20 22 23 23 24 26 26 27 27 29 29 29
pswebservername PortalHTTPPort CHAPTER 7 DELEGATING PORTAL ADMINISTRATION TO MULTIPLE GROUPS Define an administrative permission list Define an administrative role Define which parts of the portal registry can be administered. Define an administrative userid CHAPTER 8 - SETTING UP SINGLE SIGNON Scenario 1 One database and one Webserver Scenario 2 Two or more databases with one web server Scenario 3 Two or more databases and two or more web servers CHAPTER 9 VERITY Introduction Verity Collections Build Process Searching a Collection Debugging Checklist CHAPTER 10 TROUBLESHOOTING Error Getting Content You must have cookies enabled in order to sign in to your PeopleSoft application. APPENDIX A SPECIAL NOTICES APPENDIX B VALIDATION AND FEEDBACK Customer Validation Field Validation APPENDIX C REVISION HISTORY APPENDIX D - BLOCKING NON-SSL CONNECTIONS FilterEntry.java FastFilterEntry.java SlowFilterEntry.java SimpleConnectionFilter.java filter
29 30 30 31 32 33 36 38 39 41 42 44 44 45 45 50 51 52 52 54 54 56 56 56 57 57 57 58 59 60 72
2/21/2002
2/21/2002
Chapter 1 - Introduction
This Red Paper is a practical guide for technical users, installers, system administrators, and programmers who implement, maintain, or develop applications for your PeopleSoft system. In this Red Paper, we discuss guidelines on how to diagnose a PeopleSoft Online Transaction environment, including PeopleSoft Internet Architecture and Portal configuration. Configuration of Batch processes is not covered in this document. Much of the information contained in this document originated within the PeopleSoft Global Support Center and is therefore based on "real-life" problems encountered in the field. Although every conceivable problem that one could encounter with Tuxedo, the PeopleSoft Application Server, or your web server is not addressed in this document, the issues that appear in this document are the problems that prove to be the most common or troublesome.
STRUCTURE OF THIS RED PAPER

This Red Paper provides guidance on a variety of aspects involved in configuring a PeopleSoft portal. It is organized into topics that prove to often be problematic for portal implementation teams. Keep in mind that PeopleSoft updates this document as needed so that it reflects the most current feedback we receive from the field. Therefore, the structure, headings, content, and length of this document are likely to vary with each posted version. To see if the document has been updated since you last downloaded it, compare the date of your version to the date of the version posted on Customer Connection.
RELATED MATERIALS
This paper is not a general introduction to environment tuning and we assume that our readers are experienced IT professionals, with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet architecture, relational database concepts/SQL, and how to use PeopleSoft applications. This document is not intended to replace the documentation delivered with the PeopleTools 8 or 8.14 PeopleBooks. We recommend that before you read this document, you read the PIA related information in the PeopleTools PeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of the information in this document eventually gets incorporated into subsequent versions of the PeopleBooks. Many of the fundamental concepts related to PIA are discussed in the following PeopleSoft PeopleBooks: PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft Internet Architecture Administration) Application Designer (Development Tools|Application Designer) Application Messaging (Integration Tools|Application Messaging) PeopleCode (Development Tools|PeopleCode Reference) PeopleSoft Installation and Administration PeopleSoft Hardware and Software Requirements Additionally, we recommend that you read the BEA documentation (in HTML format) delivered with the BEA CD-ROM, to gain a thorough understanding of the BEA products that PeopleSoft uses, Tuxedo, Jolt, and Weblogic Server 5.1. Refer to your PeopleSoft Installation and Administration book for directions on accessing the delivered BEA documentation.
Copyright PeopleSoft Corporation 2001. All rights reserved.
2/21/2002
Chapter 2 Portal Roadmap
INTRODUCTION
The initial installation of your PeolpleSoft portal is complete. The PeopleSoft installer has just departed to catch the last flight home and has left you with a portal that is configured to work for a small number of sample users. The only content in the portal is that which came pre-delivered with the product. Now what? This chapter will discuss the major areas that need to be configured to prepare your PeopleSoft portal to operate in a production environment. It will not attempt to address the details of how to configure each area, but will rather direct you to other chapters in this document as well as other PeopleSoft documents that will guide you through each task.
CONFIGURE THE NETWORK AND SERVER ENVIRONMENT

Build the physical network and server architecture necessary to support your development, testing, and production environments. Customers must plan how to address the following topics: Network Design creation of subnets with appropriate routers and switches Security appropriate use of firewalls, proxy servers, reverse proxy servers, and SSL Webserver Hardware appropriately sized servers Software configured to optimize portal performance Load Balancing solution to scale up to load requirements
Who should be involved

Network Administrators, Database Administrators
More information
Load Balancing and Network Architecture: Red Paper - Clustering and High Availability for PeopleSoft 8 - This red paper provides instructions on how to configure your network switches, subnets, DMZ, webserver load balancer, and more. Webserver Tuning: Red Paper - Online Performance Configuration Guidelines for PeopleTools 8 This red paper provides useful information on tuning the BEA Weblogic webserver. Configuring Webserver Session Cookies - This Document: Chapter 4 Session Cookies. This chapter explains how to configure the session cookies name and domain for the portal and content provider webservers.
CONFIGURE THE PORTAL

2/21/2002 The portal has a number of configuration options that facilitate its operation under a diverse set of physical environments. Once the network and server environments are in place, then portal servlet will need to be configured for the specific network and webserver configuration the customer has chosen.

Network Administrators, Webserver Administrators
More information
How to Use the Configuration Options of the Portal: This Document: Chapter 3 - Configuration Options. This chapter explains how the portal configuration properties must be used with different combinations of network configurations. Configuration Properties of the Portal: This Document: Chapter 6 - Configuration Properties for the Portal. This chapter defines the various properties in PeopleTools configuration.properties file that impact the portal.
CONFIGURE SECURITY
Establish security access control through the definition of permission lists and roles. The portal comes pre-configured with a set of roles and permissions that the customer can choose to customize or use as delivered. Roles define what groups of people have what set of permission lists. Permission lists define a group of securable objects. A comprehensive role and permission list design is necessary to best manage which users can access each piece of content in the portal. A very powerful feature of PeopleTools security is the dynamic role. User membership to these roles is defined programmatically instead of via manually updating a membership list. They can significantly simplify managing role assignments to users.

Security Administrators
More information
PeopleSoft Security Overview: PeopleBooks Library > Security > Understanding PeopleSoft Security Discusses the various options available to security administrators. Note the sections on Authentication and Signon PeopleCode, Role Assignments, and Cross System Synchronization. Overview of security roles: PeopleBooks Library > Security > Roles - This PeopleBook chapter provides an overview of how roles are defined and used to manage security access for users. It includes a discussion of using dynamic roles to automate the management of role membership. Batch process to rebuild all dynamic roles: PeopleBooks Library > Security > Setup Options and Processes > Execute Role Rules. This PeopleBook section describes the application engine program that can be used to regenerate role memberships for all dynamic roles.
2/21/2002 How to execute a role rule for one user: PeopleBooks Library > Security > User Profiles > Working with Dynamic Role Rules. PeopleCode functions used to implement dynamic role rules: PeopleBooks Library > PeopleCode Reference > PeopleCode Built-in Functions > ExecuteRolePeopleCode, ExecuteRoleQuery, and ExecuteRoleWorkflowQuery Delegating Administration of Portal Content: This Document: Chapter 7 Delegating Portal Administration to Multiple Groups This chapter discusses how to set up security to enable different organizations administering content in the portal. Configuring PeopleSoft Single Sigon: This Document: Chapter 8 Setting up Single Sigon This chapter discusses how to configure PeopleSoft systems to trust one another and enable single signon.
DEFINE USERS
Most PeopleSoft Portal customers choose to define their user population in an LDAP compatible directory server. Doing so makes single signon between PeopleSoft systems simpler and provides a centralized definition of user profiles that can be access by a variety of systems.

Security Administrators
More information
Overview of Directory Authentication: PeopleBooks Library > Security > Understanding PeopleSoft Security > Directory Server Integration. Configuring Directory Authentication: PeopleBooks Library > Security > Setup Options and Processes > Directory Authentication Directories and PeopleSoft Red Paper: Red Paper - Directories and PeopleSoft
DEFINE CONTENT
Folders and Content References
As delivered, the portal contains pre-registered content organized within a set of folders and subfolders. We will refer to this set of folders as the portal taxonomy. The taxonomy may need to be customized to fit the needs of your organization. Folders can be renamed, rearranged, or augmented as needed by your organization. Designing the taxonomy for your organization may be a significant task depending on the amount of content you wish to expose through the portal and the number of organizations within your enterprise that will contribute content. Plan for extensive design work on this taxonomy if it must support a large body of diverse content. The portal also has references to PeopleSoft application pages pre-delivered in the portal registry. These pages, like folders, can be moved to different locations within the portal taxonomy if necessary. In addition to these PeopleSoft pages the portal can contain references to any HTTP accessible document. The placement of these content references must be carefully designed in conjunction with the design of the portal taxonomy.
2/21/2002

Portal Content Administrators, Subject Matter Experts
More information
Understanding the portal registry: PeopleBooks Library > Portal Technology > Understanding the Portal Registry. This PeopleBook chapter provides a high level overview of the portal registry, folders, and content references. Managing Folders and Content References: PeopleBooks Library > Portal Technology > Using Portal Administration Features > Managing Folders and Content References. This PeopleBook chapter contains instructions on how to add, change, or delete a folder or content reference. It also provides instructions on moving a folder or content reference to a new position in the portal taxonomy.
Pagelets
Pagelets are the boxes of content that appear on the homepage. Pagelets are simply HTML documents that are designed to be size appropriate for insertion into a homepage. They can be static HTML files or dynamically generated HTML from a variety of technologies. PeopleSoft portals come with a suite of pagelets, which are built using PeopleSoft Internet Architecture (PIA) technology. Customers can create their own dynamic pagelets using PIA or any other leading web enabling technology such as Java Server Pages, Java Servlets, Microsoft Active Server Pages, Pearl Scripts, and CGI programs.

Portal Content Administrators, Portal Developers
More information
Developing Pagelets: PeopleBooks Library > Portal Technology > Developing Pagelets - This PeopleBook chapter provides instruction on how to build pagelets using PIA technologies.
CUSTOMIZE THE LOOK AND FEEL OF THE PORTAL

Customers can alter every aspect of the HTML generated by the portal to match their corporate branding requirements and web site design. This is technically an optional step to rolling out the portal to a production environment. Therefore it is left to the discretion of each organization to determine the extent of changes they wish to make to the user interface generated by the portal.

Portal Developers, Website Designer
10
2/21/2002
More information
Customizing the Portal Interface: Red Paper - Portal GUI Tips - This red paper provides instructions on how to customize the look and feel of all major aspect of the portal user interface. Everything from headers and footers, to templates and pagelet borders is covered.
Chapter 3 Configuration Options
LOAD BALANCING
Please refer to the Clustering and High Availability for PeopleSoft 8 red paper for a detailed discussion of load balancing configuration options with the PeopleSoft Internet Architecture. Load balancing the portal can be achieved by using a hardware load balancing solution to distribute load across multiple instances of the Weblogic server on multiple webserver machines. Many of todays hardware load balancers have SSL accelerating options that should also be considered. The number, and size, of web server machines and the number of web server instances per machine will vary depending load requirements and hardware selection. The hardware load balancing solution must be configured to enable sticky sessions which ensure that all requests from a users browser session are delivered to the same web server session. Multiple web server sessions on a single machine are recommended to keep the heap size of the JVM manageable and allow Java garbage collection to work optimally. Please refer to the Online Performance Configuration Guidelines for PeopleTools 8 Red Paper for a useful discussion on tuning the BEA Weblogic webserver and Java Virtual Machine.
Load Balancing Alternatives

There are three options that may be used to load balance the portal, a simple WebLogic cluster, an advanced WebLogic cluster, and an Generic Webserver Cluster.
11
2/21/2002
Simple Weblogic Cluster

In a simple Weblogic cluster there are one or more Weblogic instances per webserver host and there are more than one webserver hosts for redundancy. There is one WebLogic proxy server running on its own independent host. The architecture diagram is shown below:
Figure 1: Simple Weblogic Cluster - Please refer to the Clustering and High Availability for PeopleSoft 8 red paper for a detailed discussion of the advantages and disadvantages of this load balancing option, as well as instructions on how it can be configured. Configuration Properties Configure the portal to use the server name and port of the Proxy Host instead of the server name and port of its Webhost. Edit the configuration properties file for each web server instance and change the following properties: Configuration Property pswebservername DefaultPort Value The DNS name of the ProxyHost. The port the WebLogic proxy is listening on for either HTTP or HTTPS depending on how you have defined the Portal content provider.
Example:
pswebservername=portal.corp.com defaultPort=443
Content Provider setup Follow the directions in Chapter 5 to configure the portal content providers. Update the two server names in the URLs for the Portal and PortalServlet content providers to point to the server name and port of the load balancer. Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
12
2/21/2002 UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';
Advanced Weblogic Cluster

Use this architecture only if you cannot use the Generic Webserver Cluster discussed in the next section. This architecture improves the Simple Weblogic cluster by removing the single point of failure of the Weblogic proxy server. High Availability is achieved by using a load balancer. The architecture diagram is shown below:
Figure 2: Advanced Weblogic Cluster - Please refer to the Clustering and High Availability for PeopleSoft 8 red paper for a detailed discussion of the advantages and disadvantages of this load balancing option, as well as instructions on how it can be configured. Configuration Properties Configure the portal to use the server name and port of the Proxy Host instead of the server name and port of its Webhost. Edit the configuration properties file for each web server instance and change the following properties: Configuration Property pswebservername DefaultPort Value The DNS name of the load balancer The port the hardware load balancer is listening on for either HTTP or HTTPS depending on how you have defined the Portal content provider.
Example:
pswebservername=portal.corp.com defaultPort=443
Content Provider configuration Follow the directions in Chapter 5 to configure the portal content providers. Update the two server names in the URLs for the Portal and PortalServlet content providers to point to the server name and port of the load balancer.
13
2/21/2002 Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet'; Hosts file configuration The hosts file on the portal web server machines (WebHost1 and WebHost2 in figure 1 above) may have an entry that directs DNS requests for the portal content provider server name (portal.corp.com) back to the local WebHost. This will allow the portal to make requests for content hosted on the same server directly without going back through the load balancer. Example hosts file on WebHost1 123.123.123.10 portal.corp.com
Generic Webserver Cluster

This configuration requires PeopleTools 8.17. In a generic webserver cluster there is no need to install Weblogic proxy server and therefore one layer of indirection can be avoided. There are one or more Weblogic instances per webserver host and there are more than one webserver hosts for redundancy. This configuration is recommended for sites that need to flexible enough to have the ability to change capacity on demand. All web hosts need not be identical and load can be distributed according to host capacity (with most load balancers). High scalability is achieved by using HW load balancer to distribute the load directly across all the webserver instances. This is by far the most flexible and scalable configuration. The architecture diagram is shown below:
Figure 3: Generic Webserver Cluster - Please refer to the Clustering and High Availability for PeopleSoft 8 red paper for a detailed discussion of the advantages and disadvantages of this load balancing option, as well as instructions on how it can be configured.
14
2/21/2002 Configuration Properties This load balancing option requires that a copy of the configuration properties file be made for each web instance a place under: weblogic/myserver/psftdocs/peoplesoft8/<instance_name>/configuration.properties So on WebHost1 in our example above we would have: weblogic/myserver/psftdocs/peoplesoft8/webinstance1/configuration.properties weblogic/myserver/psftdocs/peoplesoft8/webinstance2/configuration.properties Each copy of the configuration properties file is identical, with the exception of the PortalHTTPPort property that must be set to the port the specific web instance is listening on. Configure the portal to use the server name and port of the hardware load balancer instead of the server name and port of its Webhost. Edit the configuration properties file for each web server instance and change the following properties: Configuration Property Pswebservername DefaultPort Value The DNS name of the load balancer. The port the load balancer is listening on for either HTTP or HTTPS depending on how you have defined the Portal content provider. The port the web instance is listening on.
PortalHTTPPort
Example (for WebInstance1 on WebHost1):

pswebservername=portal.corp.com defaultPort=443 PortalHTTPPort=5010
Content Provider configuration Follow the directions in Chapter 5 to configure the portal content providers. Update the two server names in the URLs for the Portal and PortalServlet content providers to point to the server name and port of the load balancer. Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet'; Web Instance configuration Each web instance must be started with a parameter identifying the name of the instance. The portal uses this parameter as the server name for HTTP requests to the PIA servlet running on the same web instance. This prevents the portals requests to PIA from being routed through the load balancer.
15
2/21/2002 Example: StartWebInstance1.cmd %JAVA_HOME%\bin\java -ms64m -mx64m -classpath %JAVA_CLASSPATH% Dweblogic.class.path=%WEBLOGIC_CLASSPATH% -Dweblogic.home=. Djava.security.manager -Djava.security.policy==.\weblogic.policy Dweblogic.system.name=webinstance1 -DPSInstanceHost=websintance1 Psweblogic startWebInstance1.sh $JAVA $JAVA_OPTIONS -ms64m -mx64m -classpath $JAVACLASSPATH Dweblogic.class.path=$WEBLOGICCLASSPATH -Dweblogic.home=. -Djava.security.manager -Djava.security.policy==`pwd`/weblogic.policy -Dweblogic.system.name=webinstance1 - DPSInstanceHost=websintance1 PSweblogic Hosts file configuration The hosts file on the portal web server machines (WebHost1 and WebHost2 in figure 1 above) must have an entry that defines the DNS address of each web instance running on the machine. Example hosts file on WebHost1 123.123.123.10 webinstance1 webinstance2
CONFIGURING A PORTAL RUNNING UNDER SSL TO USE HTTP CONNECTIONS TO PIA ON THE SAME SERVER.
Customers often chose to run their Portal and PIA applications using SSL connections to secure the transmissions between the browser and the web server. However, defining each homepage pagelet as an HTTPS request can cause the portal's performance to degrade significantly. The answer to achieving secure transmissions between the browser and the server and acceptable homepage performance is to configure the portal to use HTTP connections whenever it needs to talk to a PIA application that is hosted on the same server as the portal.
DNS
portal.corp.com 123.123.123.100 ProxyHost 123.123.123.100 HTTPS Browser WebLogic Proxy Port: 80/443 HTTPS HTTPS
WebHost1 123.123.123.10 WebInstance 1 psportal iclientservlet HTTP WebInstance 2 psportal iclientservlet HTTP
This configuration requires changes to the PeopleTools web configuration properties file, as well as requiring a Weblogic filter be setup to block non-SSL connections except those from the portal (see Appendix D).
16
2/21/2002
Configuration Properties
Configure the portal to use the server name and port of the hardware load balancer instead of the server name and port of its Webhost. Edit the configuration properties file for each web server instance and change the following properties: Configuration Property Pswebservername PortalUseHttpForSameServer DefaultScheme DefaultPort Value The DNS name of the web proxy or load balancer true https The port the web proxy or load balancer is listening on for HTTPS. The value of this property varies depending on the load balancing option selected by the customer. Simple WebLogic Cluster The port the WebLogic Proxy is listening on for HTTP Advanced WebLogic Cluster The port the WebLogic Proxy is listening on for HTTPS Generic Webserver Cluster The port the web instance is listening on for HTTP
PortalHTTPPort
Examples using the configuration examples from the load balancing option section: Simple WebLogic Cluster
pswebservername=portal.corp.com portalUseHttpForSameServer=true defaultScheme=https defaultPort=443 PortalHTTPPort=80
Advanced WebLogic Cluster (WebHost1)

Generic Webserver Cluster (WebInstance1 on WebHost1)

pswebservername=portal.corp.com portalUseHttpForSameServer=true defaultScheme=https defaultPort=443
17
2/21/2002
PortalHTTPPort=5010
Content Provider setup

Follow the directions in Chapter 5 to configure the portal content providers. Update the server name in the URLs for the Portal and PortalServlet content providers to point to the server name and port of the load balancer. Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';
USING AN SSL ACCELERATOR

It is recommended that customers use an SSL accelerator in front of their load balancer for optimal performance.
DNS
portal.corp.com 123.123.123.100 ProxyHost 123.123.123.100 HTTPS Browser SSL Accelerator port 443 HTTP WebLogic Proxy Port: 80/443 HTTPS
WebHost1 123.123.123.10 WebInstance 1 123.123.123.11 Port: 5010/5011 WebInstance 2 123.123.123.12 Port: 5020/5021
The configuration is very similar to that for configuring a portal running under SSL to use HTTP connections to PIA on the same server, however you must change the default port to point to the port that the SSL accelerator is configured to listen on. Note: you must continue to configure WebLogic to listen for HTTPS request, even though the accelerator will intercept all SSL connections. Failure to do so will cause the portal to not function correctly.
18
2/21/2002 Configuration Property pswebservername PortalUseHttpForSameServer DefaultScheme DefaultPort PortalHTTPPort Value The DNS name of the load balancer true https The port the SSL accelerator is listening on The value of this property varies depending on the load balancing option selected by the customer. Simple WebLogic Cluster The port the WebLogic Proxy is listening on for HTTP Advanced WebLogic Cluster The port the WebLogic Proxy is listening on for HTTP Generic Webserver Cluster The port the web instance is listening on for HTTP
Example: Simple WebLogic Cluster



19
2/21/2002

Follow the directions in Chapter 5 to configure the portal content providers. Update the server name in the URLs for the Portal and PortalServlet content providers to point to the server name of the web proxy or load balancer and the port of the SSL accelerator. Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
USING A REVERSE PROXY SERVER
Customers may want to set up a "DMZ" in front of the portal web server. This helps prevent unauthorized access to the portal web server and creates a more secure environment. A "DMZ" is typically configured with a firewall allowing access to a reverse proxy server, which relays incoming request through a second firewall to the portal webserver. The second firewall is configured to only allow connections from the reverse proxy server.
WebHost1: /etc/hosts
portal.corp.com 123.123.123.110
DNS
portal.corp.com 123.123.123.100 ProxyHost 123.123.123.110 HTTPS Browser Firewall HTTPS HTTPS HTTPS WebLogic Proxy Port: 80/443 HTTPS WebHost1 123.123.123.10 WebInstance 1 123.123.123.11 Port: 5010/5011 WebInstance 2 123.123.123.12 Port: 5020/5021
Reverse Proxy Server portal.corp.com IP: 123.123.123.100 Port: 443
Firewall
The configuration is very similar to that for configuring a portal running under SSL to use HTTP connections to PIA on the same server, however you must make the following adjustments.
20
2/21/2002 Configuration Property Pswebservername PortalUseHttpForSameServer DefaultScheme DefaultPort PortalHTTPPort Value The DNS name of the reverse proxy server. true https The port the reverse proxy server is listening on for HTTPS. The value of this property varies depending on the load balancing option selected by the customer. Simple WebLogic Cluster The port the WebLogic Proxy is listening on for HTTP Advanced WebLogic Cluster The port the WebLogic Proxy is listening on for HTTP Generic Webserver Cluster The port the web instance is listening on for HTTP
Example: Simple WebLogic Cluster



21
2/21/2002

Follow the directions in Chapter 5 to configure the portal content providers. Update the server name in the URLs for the Portal and PortalServlet content providers to point to the server name and port of the reverse proxy server. Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
Hosts file setup

Environments using the Simple WebLogic Cluster option for load balancing must have an entry in the hosts file on the web host that directs DNS requests for the content provider server name (the reverse proxy server) to the load balancer or web proxy. This will allow the portal to make requests for content hosted on the same server without going back through the reverse proxy server. The hosts file is already setup for the Advanced WebLogic Cluster option and is not needed with the Generic Webserver Cluster option. Example for a Simple WebLogic Cluster web host: 123.123.123.110 portal.corp.com
CONFIGURING THE PORTAL TO USE A PROXY SERVER TO ACCESS THE INTERNET.

It is often necessary for the portal to be running on a server that is connected to a secured subnet that does not have direct access to the Internet. A proxy server is often setup to regulate access to the Internet. In this case the portal must be configured to communicate with the proxy server in order to access these networks.
22
2/21/2002
For information on how to configure the portal to make HTTP(S) requests via a proxy server see PeopleBooks Library > Portal Technology > Miscellaneous Portal Information > HTTPS Support Through a Proxy Server.
Chapter 4 - Session Cookies

The BEA Weblogic and Apache JServ webservers use browser cookies to establish session identity. These cookies have a default name that is used to retrieve the cookie on each request to the webserver. In an environment where multiple Weblogic or JServ webservers are in use with the portal it is necessary to define unique session cookie names between web servers to prevent one cookie from overwriting a cookie of the same name set by a different web server. Below are the procedures for setting the session cookie name and domain for both Weblogic and Apache/JServ. These procedures will make reference to the term PIAInstallName that represents a single logical instance of a webserver running a PeopleSoft application. As an example, consider a customer who has the following environments: Production: Test: HRMS, Employee Portal HRMS, Employee Portal
Development: HRMS, Employee Portal. This environment would normally have six webservers, one for each product in each environment and would require each webserver to use a distinct session cookie name. We will give each webserver a distinct PIAInstallName: Production: Test: "PS_HRMS", "PS_Portal"
"PS_HRMS_Test", "PS_Portal_Test"
Development: "PS_HRMS_Dev", "PS_Portal_Dev"
W EBLOGIC SESSION COOKIE SETTINGS.

23
2/21/2002 Edit the ..\weblogic\weblogic.properties file and add the following two lines: weblogic.httpd.session.cookie.name=<PIAInstallName>_PSJSESSIONID weblogic.httpd.session.cookie.domain=<AuthTokenDomain> Where: <PIAInstallName> = A distinct name from that of other WebLogic webservers that have PeopleTools installed. <AuthTokenDomain> = The domain used to set up single signon between PeopleTools systems. See the section on the AuthTokenDomain configuration property in Chapter 6 for more information on defining this domain. Example: weblogic.httpd.session.cookie.name=PS_HRMS_Test_PSJSESSIONID weblogic.httpd.session.cookie.domain=.corp.com Restart the Weblogic webserver. See http://www.weblogic.com/docs51/admindocs/http.html#session for more information of configuring WebLogic session cookies.
APACHE/JSERV SESSION COOKIE SETTINGS.

You have to define unique JServ "zones" in order to have session cookies with unique names. Here are the steps to rename the zone that is installed by default:
1. Edit the file ..\Apache JServ 1.1.2\conf\jserv.properties Change the name of the zone. For example: Change
zones=root root.properties=C:\Program Files\Apache JServ 1.1.2\servlets\zone.properties
to
zones=<PIAInstallName> <PIAInstallName>.properties=C:\Program Files\Apache JServ 1.1.2\servlets\zone.properties
Where <PIAInstallName> = A distinct name from that of other WebLogic webservers that have PeopleTools installed. Example:
zones=PS_HRMS_Test PS_HRMS_Test.properties=C:\Program Files\Apache JServ 1.1.2\servlets\zone.properties
24
2/21/2002
2.
Edit the file ..\Apache JServ 1.1.2\conf\jserv.conf Bind the servlets directory to the new zone name. Change
ApJServMount /servlets /root ApJServMount /servlet /root
to
ApJServMount /servlets /<PIAInstallName> ApJServMount /servlet /<PIAInstallName>
Where <PIAInstallName> = A distinct name from that of other WebLogic webservers that have PeopleTools installed. Example:
ApJServMount /servlets /PS_HRMS_Test ApJServMount /servlet /PS_HRMS_Test
3. Edit the file ..\Apache JServ 1.1.2\servlets\zone.properties. Set the domain of the session cookie by changing the session.topleveldomain property. Change
#session.topleveldomain=.foo.com
to
session.topleveldomain=<AuthTokenDomain>
Where <AuthTokenDomain> = The domain used to set up single signon between PeopleTools systems. See the section on the AuthTokenDomain configuration property in Chapter 6 for more information on defining this domain. Example:
session.topleveldomain=.corp.com
4. Restart your Apache webserver. See http://java.apache.org/jserv/zones.html for more information of configuring JServ zones.
Important note regarding session cookie names. The cookierules.xml file has been designed to work with the session cookie naming convention that all PeopleSoft webserver session cookie names contain the string "PSJSESSIONID". If you choose not to follow this convention, you will need to add a section to cookierules.xml to specify that the session cookie must be deleted upon logout. For example, if your session cookie name is MYSESSION, then you must add the rule:
25
2/21/2002 <cookie name="MYSESSION" secure="false" > <delete_on_logout delete="true" /> </cookie>
Chapter 5 Portal Content Providers

The portal depends upon the configuration of two content provider definitions in the portal database. Content providers define a web server and path used by the portal to access one or more web pages or applications. The portal has two servlets that must be registered as content providers in order for the portal to function properly. The Portal content provider This content provider defines the PeopleSoft servlet named iclientservlet that responsible for serving up PeopleSoft Internet Architecture pages. All pages and pagelets that are delivered with the portal, including the portal administrative pages are rendered by this servlet. The PortalServlet content provider This content provider defines the PeopleSoft servlet named psportal that is responsible for assembling homepages and pages wrapped by portal templates. Both of these content providers must be configured to point to the DNS name of the hardware device that each users browser will connect to. In a simple environment, this device would be the webserver that the PeopleSoft servlets are running on. In a more complicated environment, the device the browser is connecting to could be a load balancer or reverse proxy server.
CONFIGURING THE PORTAL CONTENT PROVIDERS

Go to Start > Programs > PeopleTools 8.1x > Data Mover Open the ../scripts/PORTAL_SETUP.DMS file. Update the two server names in the URLs for the Portal and PortalServlet content providers to point to the server name of the device that the end users browser will connect to. Make sure the scheme indicates the proper connection type. If you plan to use SSL connections then the scheme must be set to https. Run the data mover script.
Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'http://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';
UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'http://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';
26
2/21/2002
Chapter 6 Configuration properties for the portal

There are a number of configuration options within the configuration.properties file that can be used to control how the portal behaves in various network configurations. You can find the configuration.properties file located on the webserver under: ../psftdocs/<sitename>/configuration.properties Example Windows: Unix: C:\weblogic\myserver\psftdocs\peoplesoft8\configuration.properties /weblogic/myserver/psftdocs/peplesoft8/configuration.properties
AUTHTOKENDOMAIN
This property defines the DNS domain that the portal is running under. This property is used extensively throughout the PIA and portal runtime systems and it must be set for all websites, both portal and content. Some of the features that depend upon this setting are: Single Signon between PeopleSoft applications. Failure to set the AuthTokenDomain correctly will prevent the PeopleSoft authentication cookie from being passed to the target PeopleSoft application that will force the target system to re-authenticate the user. Cross frame JavaScript updates between PIA and the portal. Failure to set the AuthTokenDomain correctly on the portal and other PIA applications will cause JavaScript security errors to appear in the browser when PIA pages are access through a portal frame based template (the default template that all PIA pages are displayed through is frame based). Cookie sharing between the portal and both PeopleSoft and third party web applications. If cookies need to be shared between web applications then each of the web applications must be accessed over a common domain name. PeopleCode global variable sharing between components running on the homepage and components running within a frame. Failure to set the AuthTokenDomain correctly on the portal and other PIA applications will cause a new session to be created on the PIA webserver when the user accesses a component through a frame based template.
Webservers that provide content to the portal that wish to enable single signon or cookie sharing must run under a single domain. This domain must be defined in the following four areas: 1. The domain set for the AuthTokenDomain configuration property on the web server. ..WebLogic/myserver/psftdocs/configuration.properties AuthTokenDomain=.corp.com
Warning: Note that you need the leading ".". So it is ". corp.com not "corp.com"
2.
The domain set in the forwarding domain rule defined in the cookierules.xml file on the web server. ..WebLogic/myserver/psftdocs/cookierules.xml 27
2/21/2002 <cookie name="*" secure="false" > <forward domain="*.corp.com" /> <delete_on_logout delete="true" /> </cookie> 3. The domain of the webserver session cookie. See the chapter on Session Cookies for more information on defining session cookies for a webserver. Apache: ../Apache JServ 1.1.2/servlets/zone.properties session.topleveldomain=.corp.com Weblogic: ../WebLogic/weblogic.properties weblogic.httpd.session.cookie.domain=.corp.com 4. The domain of the URI of the portal content providers in the database. ..<pshome>/scripts/PORTAL_SETUP.dms UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'http://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal'; UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'http://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet'; In addition to the setting the portals domain in the four areas described above, the same domain must be set for each PeopleSoft application that the portal interacts with.
portal.corp.com crm.corp.com hrms.corp.com sales.i
Corporate Intranet
Browser
Browser
Browser
In the example above the CRM and HRMS webservers would need to be defined with DNS names that include the same domain name as the DNS name of the portal web server. They would also each need the AuthTokenDomain property set to this domain in their configuration properties file. Web servers that do not have the same server domain as the portal can still be used to serve content to the portal. However, cookies set by the portal will not be forwarded to these servers. The sales server in our example above would be able to provide pages and applications to the portal, but it would not be able to host a PeopleSoft application that supported single signon with the portal. If a content providing system is a PeopleSoft 8 system it must have its AuthTokenDomain set
28
2/21/2002 Note: The example above would also require that unique session cookies are defined for each web server. Please review Chapter 4 Session Cookies for more information.
PORTALUSEHTTPFORSAMESERVER
Setting this property to true tells the portal to use HTTP connections for requests to the PIA servlet running on the same webserver as the portal. When this property is set to true the DefaultScheme, DefaultPort, and PortalHTTPPort properties must also be set. Setting this property is necessary when the portal webserver is behind an SSL accelerator or when SSL is terminated on a device in front of the portal web server such as a reverse proxy server. This property can also be used to improve the performance of homepage pagelets that are provided by the PIA servlet running on the same webserver as the portal when that webserver is receiving SSL requests directly (i.e. SSL has not been terminated by a device in front of the web server). See Chapter 3 Configuration Options for more information on using the PortalUseHttpForSameServer configuration property.
DEFAULTSCHEME
This property is used to override the scheme used by PIA and the Portal to construct HREFs. When this property is not set the scheme of the incoming request to the PIA servlet is used to construct HREFs on a PIA or Portal page. It is necessary to set this property when the browser makes an SSL connection and SSL is terminated prior to the PIA servlet using a device such as an SSL accelerator or a reverse proxy server, or by setting the configuration property PortalUseHttpForSameServer to true. In this situation the scheme of request to the PIA servlet is HTTP, however PIA must generate HREFs with an HTTPS scheme.
DEFAULTPORT
This property is used to override the port used by PIA and the Portal to construct HREFs. When this property is not set the port of the incoming request to the PIA servlet is used to construct link on a PIA or Portal page. It is necessary to set this property when the port that the PIA servlet is accessed through is different than the port the browser connected to. This can occur when an SSL accelerator is used or when a reverse proxy server (RPS) is configured in front of the webserver, and the RPS listens on a different port than the webserver. It is also necessary when the configuration property PortalUseHttpForSameServer to true or when a load balancer is in use directly request to webservers listening on different ports. In these situations PIA must generate HREFs with the port used by the browser for its initial connection.
PSWEBSERVERNAME
This property is used to override the server name used by PIA and the Portal to construct HREFs. When this property is not set the server name of the incoming request to the PIA servlet is used to construct HREFs.
29
2/21/2002 It is necessary to set this property when the server that the PIA servlet is on is different than the server the browser connected to. This can occur when a reverse proxy server (RPS) or load balancer is configured in front of the webserver. In these situations PIA must generate HREFs with the server used by the browser for its initial connection.
PORTALHTTPPORT
Used by the portal to know what port to use for HTTP connections to the PIA servlet. This property is only used in conjunction with the PortalUseHttpForSameServer property.
Chapter 7 Delegating portal administration to multiple groups

The portal administration pages will only allow a user to administer pages to which their userid has access. In order to segment the administration of the portal registry between different groups of people it will be necessary to create a set of userids, roles, and permission lists for administrative access that are separate from the userids, roles and permission lists assigned to people for general purpose access to the portal. For example, a user that is allowed to enroll in benefits and enter customer interactions as a general purpose user would not be allowed to administer both sets of pages. Instead, a new userid is created that is granted roles that only have access to the content that the user is allowed to administer. Although the administrative userid has access to view the links and administer the folders and content references, this userid does not actually have access to the application pages (e.g. actually processing customer interactions) because it doesnt have the necessary menu item security in the PeopleSoft application. Create one administrator role and permission list for each segment of the portal you wish to administer. For example, you might create a permission list such as HRAdmin with a corresponding role. The HRAdmin role would be granted access to the HRAdmin permission list. Each person you wish to grant administrative privileges to would be given an administrator userid that is distinct from their userid used for general-purpose access to the portal.
Note: The terms Administrative Userid, Administrative Role, and Administrative Permission List are used to describe standard PeopleTools userid, role, and permission list security objects that have been created specifically for administrative purposes. For example Jane Doe might be given a userid called Admin-Jane Doe in addition to her general-purpose userid of Jane Doe. The userid Admin-Jane Doe would then be assigned to one or more of the administrative roles such as HRAdmin. When Jane logs in with her Jane Doe userid, she can not access the portal administration pages. She can only access the content that her general purpose roles provides access to. When she logs in with here AdminJane Doe userid, Jane can only see the HRMS content that she is allowed to administer along with the portal administration pages. The number of administrative roles you will need will depending on how granularly you wish to segment the content in the portal. Consider the example portal registry below:
30
2/21/2002 We will create a segment in this registry for the HRMS department that will manage all content under the Process Global Payroll and Benefits folders. The HR department will also manage some of the content under the Employee Self-Service and Manager Self-Service folders.
DEFINE AN ADMINISTRATIVE PERMISSION LIST

Create the administrative permission list: HRAdmin
Add the portal administrative pages to the list of pages that an HR Administrator can access. . This will eventually give the Jane Doe administrative userid the ability to view and update the Portal admin pages. Permission to edit individual crefs and folders is granted in a following step.
Grant authorization to access all components within the portal administration and portal personalize homepage menus.
31
2/21/2002
Grant access to the following web libraries with full access to all scripts within each library.
DEFINE AN ADMINISTRATIVE ROLE

Create the administrative role: HRAdministrator Assign the HRAdmin permission list to the HRAdministrator role.
32
2/21/2002
DEFINE WHICH PARTS OF THE PORTAL REGISTRY CAN BE ADMINISTERED.

Use cascading permission lists to indicate which parts of the portal registry the permission lists will grant administrative access to. Add the HRAdmin permission list to the folders that have HR content within them. Specify Cascade on those folders that only contain content that is managed by the HR Administrator. You only need to specify a cascading permission at the highest point in the folder tree where HR only content begins. In our example we are adding HRAdmin to the Benefits folder that lives at the top of the folder hierarchy.
Add the HRAdmin permission list to the Portal Administration folder and specify Cascade.
33
2/21/2002
All content registered below these folders will now automatically be assigned the correct administrative permission list. All userids that have the HRAdministrator role assigned to them will now be able to administer all content below the Benefits and Process Global Payroll folders. These userids will not have access to administer content in any of the sales or customer service folders. Manually assign permission lists to folders that contain content administered by more than one group. Assign the HRAdmin permission list to the Employee and Manager Self-Service folders. Do not make these permission lists cascade.
34
2/21/2002
These folders will contain content references to application pages managed by both groups. Our goal is to ensure that the HRMS Administrator can only administer content references owned by the HRMS department. If the HRAdmin permission list were made to cascade, then all content references under the Employee Self-Service folder, including those owned by customer service, would be visible to the HRMS Administrator. If content below these folders is organized in department specific subfolders then cascading permission lists can be used at the subfolder level as in the above section.
If a folder contains content references that belong to more than one group, then each content reference will need to be individually assigned to the correct administrative permission list. Make sure that you assign the permission list to each of the parent folders that the content reference is defined under. In the example below, the HRAdmin permission list would be added to the Emergency Contacts content reference as well as the Personal Information and Employee Self-Service (this was already added in our example in an earlier step) folders. These permission list assignments should not be made to cascade.
35
2/21/2002
Assign the administrative permission list to appropriate pagelets and pagelet categories Indicate which homepage pagelets can be administered via this permission list by assigning it to pagelet category folders and pagelet content references. Within the portal administration structure and content application navigate to Base Portal Data > Pagelets. Add the HRAdmin permission list to each folder containing pagelets that an HR Administrator should be able to access. If a folder contains pagelets that are to be managed by only one group, then you can set the cascade option on the HRAdmin permission list assignment. All pagelets within this folder will be accessible to the HRAdministrator role. If a folder contains pagelets managed by more than one group, then do not set the cascade option on the HRAdmin permission list assignment to the folder. In this case you will need to assign the HRAdmin permission list to each content reference within the folder that an HR Administrator should be able to change.
DEFINE AN ADMINISTRATIVE USERID

Now that you have administrative roles and permission lists defined which grant access to subset of the portal registry, you must create new administrative userids for the people who are to administrator content in the portal. Do not assign the new administrative roles to a person general-purpose userid. Doing so will allow them to access the portal administrative pages and make administrative changes to objects that the user has general purpose access to as well as the content they have administrative access to. For example, a user that is allow to enroll in benefits and enter customer interactions as a general purpose user would not be allowed to administer both sets of pages. Instead, create a new administrative userid that only has access to the content they are allowed to administer. Create the userid: Admin-JaneDoe Add the HRAdministrator role to the Admin-JaneDoe userid.
36
2/21/2002
Log in as Admin-JaneDoe and you will see the following navigation pagelet:
Navigate to the Structure and Content page within Portal Administration and you will see:
The Admin-JaneDoe user id can now administer only the content that the HR department is responsible for. Navigating into the Benefits folder you will see:
37
2/21/2002
Navigating to the Employee Self-Service folder should look like this:
Chapter 8 - Setting up Single Signon
38
2/21/2002 Single Sign on is a feature in Tools 8.1 that allows a user to log in to a second PeopleSoft application server without typing their id and password -- after they've successfully logged in to a first application server by typing their id and password.
This feature is critical to our Portal -- since the main purpose of the Portal is to aggregate application content from various application servers. Users wouldn't tolerate a bunch of signon screens. Single signon is supported with PIA as well.
SCENARIO 1 ONE DATABASE AND ONE W EBSERVER

In this scenario you have one database, and you want to sign on to the portal -- signing on to the portal is the common way you can use single signon with one database. While single signon is configured at the database level (i.e. you specify time out minutes and trusted nodes for the entire database) its actually used any time you have two different PIA servlets connecting to the same database. When you sign onto the portal, there are two servlets involved -- the portal servlet, which proxies content and assembles pages, and the iClient servlet which executes iScripts to actually mark up the navigation header, the breadcrumbs etc. Since the user only wants to see one signon page, we use single signon to propagate the login from one servlet to the next. Step 1. Make sure there is a "Local Message Node" defined in app designer. You can see if a local node is defined by doing File --> Open --> Message Node, hit "enter" to search for all nodes defined for this system
The "X" in the "Local" column means the QE_LOCAL node is the "Local" node for this system.
You control which node is "Local" using the "Use" tab on the message node properties page. Open "QE_LOCAL" and go to File --> Object Properties
39
2/21/2002
If your system doesn't have a local node define, define one using this dialog. Step 2. Make the local node a "Trusted" node for single signon, for your system. You control the trusted nodes using Maintain Security--> Setup --> Single Sign on You'll see this page
Make sure you're local node is in the list of "Trust Authentication Tokens issued by these Nodes" Make sure the timeout min. is set to something reasonable like 720. Note that 720 minutes would be the maximum age of a token that this system will accept. This timeout parameter is controlled by the system accepting the token, not the system issuing a token. The system accepting a token for authentication controls how old of a token it will accept, and which systems it trusts.
40
2/21/2002
SCENARIO 2 TWO OR MORE DATABASES WITH ONE WEB SERVER

This scenario is similar to scenario 1, except you have to set up the application database to "trust" the portal database. You also have one webserver with two different sites, one for the portal and one for a PeopleSoft application. Step 1. Make sure databases A and B both have local nodes set up. For this example, we'll call the local node in A "NODE_A" and in B "NODE_B". See the instruction in Scenario 1 for how to set up local nodes. Step 2. Make sure databases A and B both have node definitions for each other. For example, A has a node definition called "NODE_B" and B has a node definition called "NODE_A". Here's what it should look like in A.. (B would be the same except the X would be by B)
Step 3. Make sure the node password for "NODE_A" node definitions in A and "NODE_A" in B match. Do the same for "NODE_B" in both databases. You set the node password for a node on the "Use" tab of the properties page for the definitions. Note that by default, nodes have a blank password, or "". If you create two new node definitions in two databases, and leave the node password field blank (don't change it). Single signon will work. If you change one however, and not the other, it won't work.
41
2/21/2002
Step 4. Make sure the nodes for the PeopleSoft application "Trusts" the portal node for single signon. In node A (the application database) add "NODE B" to the "Trust these Nodes list".
SCENARIO 3 TWO OR MORE DATABASES AND TWO OR MORE WEB SERVERS

Follow the steps for Scenario 2. In addition, you need to do a couple more things... Since single signon is implemented using browser cookies, you have to configure things so the user's browser sends the single signon cookie to each web server / machine they want to "single sign" on to. By default, the browser only sends cookies back to the machine that set the cookie. So if web server a.peoplesoft.com sets a cookie (the user types their id and password into the signon page on A) , the browser will only send it back there.
42
2/21/2002 It won't send it to b.peoplesoft.com. You can make the browser send the single signon cookie to all servers at peoplesoft.com by following the instructions for setting an AuthTokenDomain in Chapter 6. You will also need to make sure that the session cookie names for each web server are unique by following the instruction in Chapter 4 Session Cookies. When you change AuthTokenDomain, you may have to change the way you navigate to the server using the browser. You have to reference the web server using the full domain name, rather than just the machine name. For example, if you used to navigate to http://a/peoplsoft8/signon.html, you now have to go to http://a.corp.com/peoplesoft8/signon.html. Single signon from a.peoplesoft.com to b.peoplesoft.com won't work unless you have static IP addresses and DNS entries, or you update your hosts file as described in the next paragraph. If you're doing single signon between machines that don't have DNS entries, you can still do single signon by modifying the "hosts" file on the machine that's running the web browser. For example, if I'm using machine a.peoplesoft.com to signon to the web server a.peoplesoft.com, then single signon to b.peoplesoft.com, I'd update the "../etc/hosts" file on a.peoplesoft.com as follows..
# Copyright (c) 1993-1999 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # # 102.54.94.97 38.25.63.10 rhino.acme.com x.acme.com # source server # x client host
127.0.0.1 216.131.221.88 216.131.221.33
localhost a.peoplesoft.com b.peoplesoft.com
43
2/21/2002
Chapter 9 Verity
INTRODUCTION
This will cover the PeopleTools 8.1x codeline. PeopleSoft uses a third party search engine technology to achieve superior performance and search results with Portal content. This technology is called PeopleSoft Search or Verity Search after the company who owns the technology. Below is a basic architectural diagram of how Verity works within the PeopleSoft architecture.
URLs
Application Server
Web Server
PeopleCode Search API Files
Verity Collection
Verity Binaries
BIF File DAT File
PeopleSoft DB
App. Engine PeopleCode Verity Collection
Cached Info Data
Process Scheduler
The majority of the ties between PeopleSoft and Verity occur within an API. You can not see the details of how the Portal Collections are built or queried. This document will help you understand what is going on in the background to better debug any Verity errors.
44
2/21/2002
VERITY COLLECTIONS
A Verity Collection is a collection of data in a format that can be searched by the Verity binaries. The build process takes data from the Portal Registry or file directories and creates a Collection. This collection is searched with Verity binaries through a PeopleSoft API into Verity. This API masks much of the details around this integration.
PeopleBooks use of Verity is very different then PeopleTools use of Verity. Successful PeopleBooks searching does not indicate that your PeopleTools will be successful. They are separate configurations. PeopleSoft finds its collections through a collection path, a collection name, and a language. Your Application Servers and Process Scheduler Server have the following configuration property in psappsrv.cfg and psprcs.cfg: ;------------------------------------------------------------------------; Verity Dir / PSVERITYDIR ; This is the directory where the Verity toolset is installed. ; NOTE: this is not used in 8.1x, since Verity is installed in the app server. Verity Dir= ; Search Collection Path ; This is an alternate directory that you can put non-portal collections in. Search Collection Path=C:\PeopleTools\pt814\data\search The Verity Dir property is not currently used in the PeopleTools 8.1x codeline. You can ignore this setting. The important setting is the Search Collection Path. This points to the root directory of where your collections are stored.
Your Process Scheduler Server must match your Application Server setting for PeopleSoft to find your collection. PeopleSofts API will concatenate the Search Collection path with the collection name and then the database name and then the language. The portal collection name is hard-coded as Portal, so if your database were called PA8SP2, your collection path would be interpreted as: C:\PeopleTools\pt814\data\search\Portal\PA8SP2\Eng
This path must be accessible with permissions from your Application Server to successfully access the collection.
BUILD PROCESS
Portal Registry Collection
The Collection build runs in the Process Scheduler Server as an Application Engine process called PORTAL_INDEX. This process builds the collection in the path specified above. The first step of the process is to create an input.bif and input.xml file in the collection directory. These files are used to index the Portal Registry data.
In PeopleTools version 8.14 and earlier, input.xml was named input.dat. If you are using this version of PeopleTools, check for input.dat instead. If your build fails, make sure input.bif and input.xml were created successfully first.
45
2/21/2002 If your build fails, make sure input.bif and input.xml were created successfully first. If these files are not getting generated, it is not a Verity problem. You will want to check your paths for accuracy and check your directory permissions for access. Make sure your Process Scheduler Server can write these files. The files have this type of structure: Input.bif
# Document 0 VdkVgwKey: {Portal}?ICType=Panel&Menu=PORTAL_PERS_HOMEPAGE&Market=GBL&PanelGroupName=PORTAL_HP_REMOVE VALID_FROM_DATE: 2000-06-12 VALID_TO_DATE: CREATION_DATE: 2000-06-12 CONTENT_PROVIDER: Portal URL: ?ICType=Panel&Menu=PORTAL_PERS_HOMEPAGE&Market=GBL&PanelGroupName=PORTAL_HP_REMOVE DOC_FN: D:/PeopleTools/mss/pt814/data/search/PORTAL/PRTL814/ENG/input.xml DOC_OF: 0 DOC_SZ: 814 <<EOD>>
Input.xml
<RECORD0> <NAME> Component Remove Confirm Page </NAME> <DESCRIPTION> Home page component removal </DESCRIPTION> <AUTHOR> PTDMO </AUTHOR> <PRODUCT> PRTL </PRODUCT> <VALID_FROM_DATE> 2000-06-12 </VALID_FROM_DATE> <VALID_TO_DATE> </VALID_TO_DATE> <CREATION_DATE> 2000-06-12 </CREATION_DATE> <CONTENT_PROVIDER> Portal </CONTENT_PROVIDER> <URL>?ICType=Panel&Menu=PORTAL_PERS_HOMEPAGE&Market=GBL&PanelGroupName=PORTAL_HP_REMOVE </URL> <PATH> Root{PORTAL_ROOT_OBJECT}.Base Portal Data{PORTAL_BASE_DATA}.Home Page{HOME_PAGE} </PATH> <ATTRIBUTES> <PORTAL_HIDE_FROM_NAV> TRUE </PORTAL_HIDE_FROM_NAV> </ATTRIBUTES> <Menu> PORTAL_PERS_HOMEPAGE </Menu> <Market> GBL </Market> <PanelGroupName> PORTAL_HP_REMOVE </PanelGroupName> </RECORD0>
These files contain relevant Portal Registry data to be searched and the security settings on that data. The input.bif file contains fields that can be searched and retrieved from the result collection. Retrieving a field value form the result collection is done through the SearchFields object and the ItembyName() method (see code example in Searching a Collection section). Input.xml contains field that can be searched, but can not be returned from the result collection. After the input.bif and input.xml are created, the PeopleSoft API calls a Verity executable called mkvdk. On Windows this is in your PS_HOME\bin\server\winx86\ directory. On Unix it is in your PS_HOME/bin directory. You can run the mkvdk command with no parameters to see all of its options. When the collection is first built, the following command is getting executed through the API. This example is in windows. Unix commands would be identical except for where the output goes. See the note below about log files. In addition, the paths would vary on Unix. mkvdk -locale englishx -create -style C:\PeopleTools\pt814\data\search\PORTAL\style
46
2/21/2002 -collection C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG -bulk -insert C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG\input.bif
47
2/21/2002 In Unix, mkvdk is a shell script wrapper for the executable, mkvdk.bin. Running mkvdk through the shell script is recommended because the shell will set up PATHs for you.
Lets break down the command line. -locale englishx This instructs the collection to be built in the English language. -create This instructs mkvdk to build the collection directory structure. This means the target collection directory is empty. If it is not empty this command will fail because of this flag. -style C:\PeopleTools\pt814\data\search\PORTAL\style This instructs mkvdk to use the style files in the specified directory. Style files determine the collection structure and properties. You should never modify these files for Portal collections! -collection C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG This instructs mkvdk to build the collection into the specified directory. -bulk -insert C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG\input.bif This instructs mkvdk to do a bulk insert into the collection structure based on this input.bif file. The input.bif file points at the input.xml file for further information. This is the verity output: mkvdk - Verity, Inc. Version 2.6.1 (_nti40, Jul 19 2000) BulkInserting into C:/PeopleTools/pt814/data/search/PORTAL/PRTL814/ENG (1) from C:/PeopleTools/pt814/data/search/PORTAL/PRTL814/ENG/input.bif (0, 0) Initializing dataset 00000001.ddd, index 00000001.did Totals (316 documents): 316 para 325 sent 5306 word (1392 Kb used) Optimizing database layout (6198 ms) Indexed 316 docs into C:/PeopleTools/pt814/data/search/PORTAL/PRTL814/ENG/00000001 Writing partition index data mkvdk done You can see that it inserted 316 documents (or records). This was successful. If there were any errors, you would see them here. Another indication of success is that you will see files inside the parts directory under the collection directory.
Inside that parts directory you should see files named 00000001.did and 00000001.ddd. The number stands for each partition of the collection. This example represents the first partition. If these files do not exist, you collection was not built. This is the command that would run if the collection already existed: mkvdk -locale englishx -purge -collection C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG This clears out the collection. The process would then run this command: mkvdk -locale englishx -collection C:\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG -bulk -insert
48
2/21/2002 C:\UserApps\PeopleTools\pt814\data\search\PORTAL\PRTL814\ENG\input.bif If you cannot get your Verity builds to work correctly, but your input.bif and input.xml files are getting generated, try to run these mkvdk commands by hand so you can view the errors. Remember that in windows you must execute the command form your PS_HOME\bin\server\winx86 directory.
The mkvdk processes will also generate log files. In windows it will be under your collection directory named Englog.out, in Unix it can be found under your PS_HOME/appserv/prcs directory named veritybuild.log. Inspect these files for errors and debug them by running mkvdk by the command line. If you run mkvdk from the command line on Unix, veritybuild.log will be found in your current working directory or in PS_HOME/data/search. Once you successfully get mkvdk running via the command line, the Application Engine process should run now.
Portal File Directory Collections

There is an APRD available to allow your Portal Search to search through file directories. You must have patch RGBIERN-XF6X8 installed to use this functionality. This process adds a new Application Engine Process, EO_PE_SIDX, to build separate collections for file directories. This allows you to search through many different file types and return links inside your portal. The process is slightly different then the Portal build process and debugging may be different. The setup screen appears below.
49
2/21/2002 The first difference is that this AE process uses a Java File object named EoPeFile. This object is used to check file existence, delete directories, create directories and run command lines. The command line to build the file directory collection above is as follows: vspider -style c:\PeopleTools\pt814\data\search\pa_epp_common\style -locale englishx -start \\cypher\docs51 -collection c:\PeopleTools\pt814\data\search\PS_EPP_FILES\Eng The example above is used under Windows. Unix paths would differ.
Because this uses a Java Object, your JVM settings must be accurate on your Application Server. JavaVM Shared Library=C:\Apps\weblogic\jre1_2\jre\bin\classic\jvm Without this setting, the build process will fail when it tries to instantiate the Java object EoPeFile. This build process uses style files stored under the \data\search\pa_epp_common\style. If you customize your Search Collection path, you must copy the pa_epp_common directory under the new path. Once you build your file collection, you will see a new directory name PA_EPP_<NAME> under your Search Collection Path. This is your new collection. Inside that directory is a set of logs under spider\log. Check those logs for more information about possible errors or bad files.
SEARCHING A COLLECTION
The Portal Registry Object has one main method to get a search object called GetSearchQuery(). The GetSearchQuery method will return the Search Query object. You then will search on the object with the Execute() method. The Execute() method has two parameters: StartPosition and ChunkSize. StartPosition and Chunksize are used to chunk search results for improved performance or user interface. Here is an example of the Portal Search: &SearchKey = "search keywords"; &StartPosition = 1; SearchResultChunkSize = 100; /*----------------------------------------------------------------------------Get a portal registry object. ------------------------------------------------------------------------------*/ &Portal = %Session.GetPortalRegistry(); /*----------------------------------------------------------------------------Open the desired portal. ------------------------------------------------------------------------------*/ &Portal.Open("PORTAL") /*---------------------------------------------------------------------------Get a search query object. ------------------------------------------------------------------------------*/ &SearchQuery = &PORTAL.GetSearchQuery(); /*---------------------------------------------------------------------------Set the text of the query the user entered ------------------------------------------------------------------------------*/ &SearchQuery.QueryText = &SearchKey /*---------------------------------------------------------------------------Execute the search passing in the starting position and "chunk size" (get me the first 20 result or the third 20)
50
2/21/2002 ------------------------------------------------------------------------------*/ &SearchResultsColl = &SearchQuery.Execute(&StartPosition, &SearchResultChunkSize); /*---------------------------------------------------------------------------Get the first result. ------------------------------------------------------------------------------*/ &SearchResult = &SearchResultsColl.First(); While (&SearchResult <> NULL) /*--------------------------------------------------------------------------Example of getting the key. In the portal case, the key is the URL, but in the general case it could be a product id or some kind of other database key. ---------------------------------------------------------------------------*/ &SearchKey = &SearchResult.Key; /*--------------------------------------------------------------------------Example of getting the Field. In the portal case, the field is the URL. Yes, it is redundant with the key but the key includes some {} around the URL and this just makes it easier to get the URL. ---------------------------------------------------------------------------*/ &URLSearchField = &SearchResult.SearchFields.ItemByName("URL") &URL = &URLSearchField.Value /*--------------------------------------------------------------------------Another example of a field using dot notation to simplify the code. ---------------------------------------------------------------------------*/ &ContentProvider = &SearchResult.SearchFields.ItemByName("ContentProvider").Value /*--------------------------------------------------------------------------Call a function to insert the result into the page. ---------------------------------------------------------------------------*/ AddStuffToPage(&URL, &ContentProvider); /*--------------------------------------------------------------------------Get the next result of the search. ---------------------------------------------------------------------------*/ &SearchResult = &SearchResultsColl.Next(); End-While; &Portal.Close();
The most common reason a search would fail is that a collection was not found or was not built. Assuming the collection was built correctly using the steps detailed in preceding sections, there may be an incorrect configuration property. Every application server used to search your Portal collection needs to point at the root collection directory in its psappsrv.cfg. The property is called Search Collection Path. This must point at the directory parent to all your collections. It is most often pointing at PS_HOME/data/search. There are unique situations where this setting is correct, but your search still fails. Contact GSC with these issues because there have been bugs associated with certain operating systems.
DEBUGGING CHECKLIST
Problems Searching on HPUX You may encounter the following error submitting a search in the search bar, when your Application Server (not your webserver or database server) is running on HPUX:
51
2/21/2002
You can work around this problem on the Application Server by doing the following: $ $ $ $ cd $PS_HOME/bin mkdir _hpux11 cd _hpux11 ln s bin ..
Veritys search path for libraries on the HPUX platform does not include the current directory, instead it expects the libraries to be found in _hpux11/bin. Symlinking this directory to where the libraries exist solves the problem. This problem should go away in PeopleTools 8.16. Is Verity installed? Check for mkvdk.exe in bin\server\winx86 or mkvdk.bin in /bin. If it is not there, you do not have Verity installed. If you are building portal search collections on file directories or URLs you must also have the vspider.exe/vspider.bin in those directories. Did your Collection Build process succeed? Did the Application Engine succeed? If not, follow the steps in this document to debug any problems. Make sure your directory security permissions allow writing the input.bif and input.xml files. Check the log files for errors and run command lines by hand to see errors first hand. Do you see files inside the collection parts directory? This is the best verification that the build succeeded. Does your Application Server configuration point to the same Search Collection Path as your Process Scheduler? Check psappsrv.cfg and psprcs.cfg Search Collection Path setting. Do these match? You must build in the same location that you are searching.
Chapter 10 Troubleshooting
ERROR GETTING CONTENT
52
2/21/2002
Examine the webserver log file: Weblogic: ../WebLogic/myserver/weblogic.log Apache: ../Apache JServ 1.1.2/logs/jserv.log Typical messages: Unable to signon to server check app server log. You will likely find an authentication error message that tells you what is wrong (e.g. node is not trusted, node password didnt match, token expired, invalid certificate, user not defined). 1. If no authentication error is in the app server log then the PeopleSoft security cookie did not get passed to the PIA webserver. This usually occurs when the AuthTokenDomain in configuration.properties is not set or set incorrectly. Make sure the content provider of the target system has the same domain as the portal web server and that this domain is set in the AuthTokenDomain configuration property. See Chapter 6 for more information on configuring this property. This also error occurs when a user personalizes their homepage prior to the AuthTokenDomain configuration being completed correctly. In this case, the error will only occur when a pagelets Edit, Minimize, or Remove icons are selected. Have the user re-save their personalization settings by navigating to the Personalize Content page and clicking on the Save button.
2.
Unable to get document there is usually a stack trace with this message. The URL that the portal tried to access is usually listed here. Issues commonly are: 1) The URL is invalid. 2) URL is valid, but the servlet cant access the page. This can happen when: a) The servlet is not talking to a required proxy server, or when it is going through a proxy server when it shouldnt. Copy the URL and paste it into a browser running on the same machine as the portal servlet to see if the webserver machine can access the URL. b) Third-party security software is preventing the call from going through (example: Netegritys SiteMinder). Possible resolution: Configure the security system to allow those calls or make sure portal servlet passes appropriate information (headers, cookies, etc) with the http call. 3) The URL returned an empty response. This can happen when an iScript returns nothing. 4) The URL is malformed can mean URL has some kind of a typo.
No such file or directory common sources of this problem are: 1. The AuthTokenDomain is not defined correctly. The AuthTokenDomain section in Chapter 6 for information on how to configure it correctly. Make sure the AuthTokenDomain does not have two periods at the beginning of its value in both the configuration.properties and cookierules.xml files.
53
2/21/2002 2. The URL is invalid. Make sure the content provider for the URL is pointing the correct path and resource on the web server. If the page is a PIA page, then make sure the content provider URI is pointing to the correct location of the iclientservlet.
YOU MUST HAVE COOKIES ENABLED IN ORDER TO SIGN IN TO YOUR PEOPLESOFT

APPLICATION.
Domain mismatch
This error is often caused by a mismatch between the domains defined for the following items: 1. 2. 3. 4. The domain of the URI of the Portal and PortalServlet content providers The domain set for the AuthTokenDomain configuration property. The domain set in the forwarding domain rule defined in the cookierules.xml file. The domain of the webserver session cookie
Make sure the domains match between these files. See Chapter 6 for more information on configuring the AuthTokenDomain configuration property.
Blank default template

Make sure that you have added a Default Template Name for the Content Provider in the Portal Database where the Content Provider is another PeopleSoft database. This is done by going to Portal Administration > General Settings > Content Providers. Do not leave the Default Template Name blank. If you leave this blank, you may encounter the error "You must have cookies enabled." when attempting to log on to the Content Provider (e.g., logging on to the HRMS or FIN database).
Appendix A Special Notices
All material contained in this documentation is proprietary and confidential to PeopleSoft, Inc., is protected by copyright laws, and subject to the nondisclosure provisions of the applicable PeopleSoft agreement. No part of this documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, including, but not limited to, electronic, graphic, mechanical, photocopying, recording, or otherwise without the prior written permission of PeopleSoft, Inc. This documentation is subject to change without notice, and PeopleSoft, Inc. does not warrant that the material contained in this documentation is free of errors. Any errors found in this document should be reported to PeopleSoft, Inc. in writing.
54
2/21/2002 The copyrighted software that accompanies this documentation is licensed for use only in strict accordance with the applicable license agreement, which should be read carefully as it governs the terms of use of the software and this documentation, including the disclosure thereof. See Customer Connection or PeopleBooks for more information about what publications are considered to be product documentation. PeopleSoft, the PeopleSoft logo, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, and Vantive are registered trademarks, and PeopleTalk and "People power the internet." are trademarks of PeopleSoft, Inc. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice. Information in this book was developed in conjunction with use of the product specified, and is limited in application to those specific hardware and software products and levels. PeopleSoft may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. The information contained in this document has not been submitted to any formal PeopleSoft test and is distributed AS IS. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While PeopleSoft may have reviewed each item for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites.
55
2/21/2002
Appendix B Validation and Feedback

This section documents that real-world validation that this Red Paper has received.
CUSTOMER VALIDATION
PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons learned from these customer experiences will be posted here.
FIELD VALIDATION
PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned from field experience will be posted here.
56
2/21/2002
Appendix C Revision History

Authors
Michael A. Hillerman, Portal Product Strategy PeopleSoft Development Andrew Bediz, Portal Product Lead PeopleSoft Consulting Todd McKinnon, Portal Development Engineer PeopleSoft Development
Reviewers
The following people reviewed this Red Paper: Michael Imperiale PeopleSoft Consulting Thomas Hassler PeopleSoft Global Support Center Stephen Bossong PeopleSoft Consulting
Revision History
1. 2. 3. 4. November 30, 2001: Published for internal review. December 13, 2001: Second revision. December 24, 2001: Initial Publication to Customer Connection. January 23, 2002: Corrected hyperlinks to Red Paper references.
Appendix D - Blocking non-SSL connections

Follow these steps to configure Weblogic to deny all non-SSL connection requests from all addresses except from the address of the portal. Follow this URL to the BEAs directions on how to install and compile the five files below: http://www.weblogic.com/docs51/examples/security/net/package-examples.security.net.html Note: SimpleConnectionFilter.java and FastFilterEntry.java are slightly different that the versions delivered as examples from BEA. These changes were made to work around problems with the classes discovered at customer sites. Edit the "filter" file and change "portalserver.mydomain.com" to match your portal webserver DNS name. Restart the webserver.
For more information on Weblogic filtering see: http://www.weblogic.com/docs51/classdocs/API_acl.html#filtering
FILTERENTRY.JAVA
57
2/21/2002
package examples.security.net;
import java.net.InetAddress;
/** * Abstract filter rule. * * @author Copyright (c) 1999-2000 by BEA Systems, Inc. All Rights Reserved. */ abstract class FilterEntry { static final int ALLOW = 0; static final int DENY = 1; static final int IGNORE = 2; private int protomask; private boolean action; protected FilterEntry(boolean action, int protomask) { this.protomask = protomask; this.action = action; } int check(InetAddress addr, int protocol) { if (match(addr) && match(protocol)) { return action ? ALLOW : DENY; } return IGNORE; } protected abstract boolean match(InetAddress addr); protected boolean match(int protocol) { return protomask == 0 || (protocol & protomask) != 0; } }
FASTFILTERENTRY.JAVA
58
2/21/2002
package examples.security.net; import java.net.InetAddress;
/** * Fast filter rule. * * @author Copyright (c) 1999-2000 by BEA Systems, Inc. All Rights Reserved. */ class FastFilterEntry extends FilterEntry { private int addrMask; private int netMask; FastFilterEntry(boolean action, int protomask, int address, int netmask) { super(action, protomask); addrMask = address & netmask; netMask = netmask; } protected boolean match(InetAddress addr) { if (addrMask == 0) { return true; } return (SimpleConnectionFilter.addressToInt(addr) & netMask) == addrMask; } }
SLOW FILTERENTRY.JAVA
import java.net.InetAddress;
/** * Slow filter rule. * * @author Copyright (c) 1999-2000 by BEA Systems, Inc. All Rights Reserved. */
59
2/21/2002
class SlowFilterEntry extends FilterEntry { private String pattern; SlowFilterEntry(boolean action, int protomask, String pattern) { super(action, protomask); this.pattern = pattern.toLowerCase().substring(1); } protected boolean match(InetAddress addr) { return addr.getHostName().toLowerCase().endsWith(pattern); } }
SIMPLECONNECTIONFILTER.JAVA
import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.io.InputStreamReader; import java.io.IOException; import java.io.LineNumberReader; import java.io.StreamCorruptedException; import java.net.InetAddress; import java.util.StringTokenizer; import java.util.Vector; import weblogic.security.net.ConnectionEvent; import weblogic.security.net.ConnectionFilter; import weblogic.security.net.FilterException;
/** * Simple rule-based connection filter example. * these rules. * * Syntax of the rule file is as follows: each rule is written on a * single line. Tokens in a rule are separated by whitespace. "#" is This example reads in * a set of rules from a file and bases its filtering decisions on
60
2/21/2002
* the comment character; everything after it on a line is ignored. * Whitespace before or after a rule is ignored. * * All rules follow this form: * * <pre> target </pre> * * where <tt>target</tt> is a specification of one or more hosts to * filter, <tt>action</tt> is the action to perform (and must be * either <tt>allow</tt> or <tt>deny</tt>), and <tt>protocols</tt> is * the list of protocol names to match (must be one of <tt>http</tt>, * <tt>https</tt>, <tt>t3</tt>, <tt>t3s</tt>, or <tt>giop</tt>; if no * protocols are listed, all protocols will match a rule). * * This example recognizes two kinds of rule: * * <ul> * * <li>A "fast" rule applies to a hostname or IP address, with an * optional netmask. If a hostname corresponds to multiple IP * addresses, multiple rules are generated (in no particular order). * Netmasks can be specified either in numeric or dotted-quad form. * Examples: * * <pre> dialup-650-555-1212.pa.example.net 192.168.81.0/255.255.254.0 192.168.0.0/16 </pre> * * Hostnames for fast rules are looked up once, at server startup * time. While this greatly reduces connect-time overhead, it can For maximal comfort of mind, use numeric * result in the filter having an out-of-date idea of what addresses * correspond to a hostname. * IP addresses instead. * * <li>A "slow" rule applies to part of a domain name. Since it * requires a connect-time DNS lookup on a client in order to perform * a match, it may be much slower than the "fast" rule, and it may * also be subject to DNS spoofing. * * <pre> *.script-kiddiez.org </pre> * deny Slow rules are specified as follows: deny allow deny t3 t3s # http and https OK # 23-bit netmask # like /255.255.0.0 action protocols Lines consisting * solely of whitespace or comments are skipped. 
61
2/21/2002
* The "*" only matches at the head of a pattern. If you * specify one anywhere else, it will be treated as part of the * pattern (and so that pattern will never match anything, since "*" * is not a legal part of a domain name). * * </ul> * * When a client connects, these rules are evaluated in the order in * which they were written, and the first rule to match determines how * the connection is treated. * permitted. * * If you want to "lock down" your server and only allow connections * from certain addresses, you can specify <tt>0.0.0.0/0 deny</tt> as * your last rule. * * Note that this example does not take full advantage of the * information provided by the connection filter. * is left as an exercise for the reader. * to use IPv6 addresses, if necessary. * * @author Copyright (c) 1999-2000 by BEA Systems, Inc. All Rights Reserved. */ public class SimpleConnectionFilter implements ConnectionFilter { /** * The name of the filter rule file. */ public static final String FILTER_FILE = "filter"; /** * This is our set of filter rules. */ private FilterEntry[] rules; /** * Construct a new connection filter. * resource in the server's classpath. * * @see #FILTER_FILE * @exception IOException a problem occurred while reading the rule * file */
If no rules match, the connection is
Further expansion
Note further that this
* example assumes IPv4 addresses, but it should be easy to convert it
This constructor attempts to
* find the rule file in either the current directory or as a
62
2/21/2002
public SimpleConnectionFilter() throws IOException { InputStream in = null; try { in = new FileInputStream(FILTER_FILE); } catch (FileNotFoundException e) { // ignore } if (in == null) { in = SimpleConnectionFilter.class.getResourceAsStream(FILTER_FILE); } if (in == null) { throw new FileNotFoundException("cannot find \"" + FILTER_FILE + "\" in current directory or classpath"); } setup(in); }
/** * Construct a new connection filter. * stream. * * @param is stream to read from * @exception IOException a problem occurred while reading the rule * file */ public SimpleConnectionFilter(InputStream is) throws IOException { setup(is); } Rules are read from the given
/** * Read rules from the given stream. * * @param is stream to read from
63
2/21/2002
* @exception IOException a problem occurred while reading the rule * file */ private void setup(InputStream is) throws IOException { LineNumberReader r = new LineNumberReader(new InputStreamReader(is)); Vector entries = new Vector(); String line; while ((line = r.readLine()) != null) { // Ignore comments, surrounding whitespace, and empty lines. int hash = line.indexOf('#'); if (hash != -1) { line = line.substring(0, hash).trim(); } if (line.length() == 0) { continue; } try { parseLine(line, entries); } catch (StreamCorruptedException e) { throw new IOException("line " + r.getLineNumber() + ": " + e.getMessage()); } catch (IllegalArgumentException e) { throw new IOException("line " + r.getLineNumber() + ": " + e.getMessage()); } } rules = new FilterEntry[entries.size()]; entries.copyInto(rules); }
64
2/21/2002
/** * Parse an individual line of the rule file. * are added to the given entries vector. * * @param line the line to parse (guaranteed not to contain * comments, surrounding whitespace, or be empty) * @param entries the running list of rules */ protected void parseLine(String line, Vector entries) throws IOException, IllegalArgumentException { StringTokenizer toks = new StringTokenizer(line); String addr = toks.nextToken(); boolean allow = parseAction(toks.nextToken()); // If it starts with a star, it's a slow rule. if (addr.startsWith("*")) { SlowFilterEntry sent = new SlowFilterEntry(allow, parseProtocols(toks), addr); entries.addElement(sent); } else { // It doesn't start with a star; it's a fast rule. // netmask. int slash = addr.indexOf('/'); int[] addrs = null; int netmask = 0xffffffff; // if no explicit netmask, require exact match if (slash != -1) { addrs = parseAddresses(addr.substring(0, slash)); netmask = parseNetmask(addr.substring(slash + 1)); } else { addrs = parseAddresses(addr); } int protomask = parseProtocols(toks); // We may have obtained multiple addresses from a DNS lookup. // Add a rule for each. Note that most DNS servers will return // multiple addresses in different orders on every lookup. Check for a Any resulting rules
65
2/21/2002
for (int i = 0; i < addrs.length; i++) { FastFilterEntry fent = new FastFilterEntry(allow, protomask, addrs[i], netmask); entries.addElement(fent); } } }
/** * Filter a client connection event. * * @param evt the connection event * @exception FilterException the connection should be rejected by * the server */ public void accept(ConnectionEvent evt) throws FilterException { InetAddress remoteAddress = evt.getRemoteAddress(); String protocol = evt.getProtocol().toLowerCase(); int bit = protocolToMaskBit(protocol); if (bit == 0xdeadbeef) { bit = 0; } // Check rules in the order in which they were written. for (int i = 0; i < rules.length; i++) { switch (rules[i].check(remoteAddress, bit)) { case FilterEntry.ALLOW: return; case FilterEntry.DENY: throw new FilterException("rule " + (i + 1)); case FilterEntry.IGNORE: break;
If the connection should be
* allowed, this method returns normally.
66
2/21/2002
default: throw new RuntimeException("connection filter internal error!"); } } // If no rule matched, we allow the connection to succeed. return; }
/** * This array is used for quick matching of protocols to bits. * should only contain protocols that the server supports. */ private static final String[] PROTOCOLS = new String[] { "http", "t3", "https", "t3s", "giop" }; It
/** * Parse a list of protocols and return a bitmask that will let us * match a protocol quickly at connect time. */ protected static final int parseProtocols(StringTokenizer toks) throws FilterException { int protomask = 0; while (toks.hasMoreTokens()) { String tok = toks.nextToken(); int bit = protocolToMaskBit(tok); if (bit == 0xdeadbeef) { throw new IllegalArgumentException("unknown protocol \"" + tok + "\""); } protomask |= bit; } return protomask; }
/**
67
2/21/2002
* Parse a single protocol description into a bit in a field. */ private static final int protocolToMaskBit(String proto) throws FilterException { if (proto == null) { return 0; } proto = proto.toLowerCase(); for (int i = 0; i < PROTOCOLS.length; i++) { if (proto.equals(PROTOCOLS[i])) { return 1 << i; } } // Magic return indicating no match. return 0xdeadbeef; }
/** * Given a string, return an array of IPv4 addresses corresponding * to that string as a host. * * @param str hostname or IPv4 address in string form */ protected static final int[] parseAddresses(String str) throws IOException { InetAddress[] addrs = InetAddress.getAllByName(str); int[] raw = new int[addrs.length]; for (int i = 0; i < addrs.length; i++) { raw[i] = addressToInt(addrs[i]); } return raw; }
68
2/21/2002
/** * Turn an address object into a single IPv4 address. */ static final int addressToInt(InetAddress addr) { byte[] roh = addr.getAddress(); int raw = 0; for (int j = 0; j < roh.length; j++) { raw |= (0xff & roh[j]) << (8 * (roh.length - j - 1)); } return raw; }
/** * Return an IPv4 netmask, as derived from a spec string. * string can either be a number, for a mask length, or a * dotted-quad mask. * * @param maskStr mask spec string */ protected static final int parseNetmask(String maskStr) throws IOException { StringTokenizer toks = new StringTokenizer(maskStr, "."); int ntoks = toks.countTokens(); try { if (ntoks == 1) { int bits = Integer.parseInt(toks.nextToken()); if (bits > 32 || bits < 0) { throw new StreamCorruptedException("bad netmask: \"" + maskStr + "\""); } return ~((1 << (32 - bits)) - 1); } int mask = 0; if (ntoks != 4) The
69
2/21/2002
{ throw new StreamCorruptedException("bad netmask: \"" + maskStr + "\""); } else { for (int i = 24; toks.hasMoreTokens(); i -= 8) { int num = Integer.parseInt(toks.nextToken()); if (num < 0 || num > 255) { throw new StreamCorruptedException("bad netmask: \"" + maskStr + "\""); } mask |= num << i; } } return mask; } catch (NumberFormatException e) { throw new StreamCorruptedException("bad netmask: \"" + maskStr + "\""); } }
/** * Parse an action and return its meaning. * deny. * * @param whatever the action string */ protected static final boolean parseAction(String whatever) throws IOException { String action = whatever.toLowerCase(); if (action.equals("allow")) { return true; } else if (action.equals("deny")) { return false; } else { throw new StreamCorruptedException("bad action \"" + action + "\""); }
True to allow, false to
70
2/21/2002
}
/** * Simple test harness. * and then check them. */ public static void main(String[] args) throws Exception { System.out.println("Enter rules on separate lines:"); ConnectionFilter cf = new SimpleConnectionFilter(System.in); LineNumberReader r = new LineNumberReader(new InputStreamReader(System.in)); String line; System.out.println("Enter addresses on separate lines:"); while ((line = r.readLine()) != null) { try { StringTokenizer toks = new StringTokenizer(line.trim()); String addr = toks.nextToken(); String proto = toks.nextToken(); InetAddress[] addrs = InetAddress.getAllByName(addr); for (int i = 0; i < addrs.length; i++) { try { cf.accept(new ConnectionEvent(addrs[i], 0, 0, proto)); System.out.println("ALLOW"); } catch (FilterException e) { System.out.println("DENY: " + e.getMessage()); } } } catch (Exception e) { e.printStackTrace(); } } } You can use this to write rules by hand,
71
2/21/2002
}
FILTER
# This is a sample connection filter file. # The following two rules deny access to all non-https connections to all # addresses, except for the portal webserver which can acess http and https. portalserver.mydomain.com 0.0.0.0/0 allow deny http http t3 t3s
72

Configuring Ps 8 Portal v1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring Ps 8 Portal v1

Uploaded by

Copyright:

Available Formats

Configuring a PeopleSoft 8 Portal

Configuring a PeopleSoft 8 Portal

STRUCTURE OF THIS RED PAPER

Chapter 2 Portal Roadmap

CONFIGURE THE NETWORK AND SERVER ENVIRONMENT

Who should be involved

CONFIGURE THE PORTAL

Who should be involved

Who should be involved

Copyright PeopleSoft Corporation 2001. All rights reserved.

Who should be involved

Copyright PeopleSoft Corporation 2001. All rights reserved.

Who should be involved

Who should be involved

CUSTOMIZE THE LOOK AND FEEL OF THE PORTAL

Who should be involved

Copyright PeopleSoft Corporation 2001. All rights reserved.

Chapter 3 Configuration Options

Load Balancing Alternatives

Copyright PeopleSoft Corporation 2001. All rights reserved.

Simple Weblogic Cluster

Copyright PeopleSoft Corporation 2001. All rights reserved.

2/21/2002 UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';

Advanced Weblogic Cluster

Copyright PeopleSoft Corporation 2001. All rights reserved.

Generic Webserver Cluster

Copyright PeopleSoft Corporation 2001. All rights reserved.

Example (for WebInstance1 on WebHost1):

Copyright PeopleSoft Corporation 2001. All rights reserved.

Copyright PeopleSoft Corporation 2001. All rights reserved.

Advanced WebLogic Cluster (WebHost1)

Generic Webserver Cluster (WebInstance1 on WebHost1)

Copyright PeopleSoft Corporation 2001. All rights reserved.

Content Provider setup

UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';

USING AN SSL ACCELERATOR

Copyright PeopleSoft Corporation 2001. All rights reserved.

Example: Simple WebLogic Cluster

Advanced WebLogic Cluster (WebHost1)

Generic Webserver Cluster (WebInstance1 on WebHost1)

Copyright PeopleSoft Corporation 2001. All rights reserved.

Content Provider setup

UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';

USING A REVERSE PROXY SERVER

Reverse Proxy Server portal.corp.com IP: 123.123.123.100 Port: 443

Copyright PeopleSoft Corporation 2001. All rights reserved.

Example: Simple WebLogic Cluster

Advanced WebLogic Cluster (WebHost1)

Generic Webserver Cluster (WebInstance1 on WebHost1)

Copyright PeopleSoft Corporation 2001. All rights reserved.

Content Provider setup

UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'https://portal.corp.com/servlets/psportal/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'PortalServlet';

Hosts file setup

CONFIGURING THE PORTAL TO USE A PROXY SERVER TO ACCESS THE INTERNET.

Copyright PeopleSoft Corporation 2001. All rights reserved.

Chapter 4 - Session Cookies

Development: "PS_HRMS_Dev", "PS_Portal_Dev"

W EBLOGIC SESSION COOKIE SETTINGS.

APACHE/JSERV SESSION COOKIE SETTINGS.

Copyright PeopleSoft Corporation 2001. All rights reserved.

2/21/2002 <cookie name="MYSESSION" secure="false" > <delete_on_logout delete="true" /> </cookie>

Chapter 5 Portal Content Providers

CONFIGURING THE PORTAL CONTENT PROVIDERS

Example: UPDATE PSPRDMCNTPRV SET PORTAL_URI_TEXT = 'http://portal.corp.com/servlets/iclientservlet/peoplesoft8/' WHERE PORTAL_CNTPRV_NAM = 'Portal';