Configuring the Portal Environment

This chapter provides an overview of the authentication domain and discusses how to:

• Configure web profiles.

• Define portal nodes.

• Implement single signon functionality.

• Override page encoding.

• Import menu groups into the portal registry.

• Improve same-server performance under Secure Sockets Layer (SSL).

• Use SSL accelerators.

• Use reverse proxy servers.

• Use firewalls with reverse proxy servers.

• Use reverse proxy servers with SSL accelerators.

• Apply load balancing.

Important! The PeopleSoft portal configuration environment has moved to a PeopleSoft Pure Internet Architecture interface, the web profile. Web profiles are documented in this chapter. A complete listing that maps PeopleTools release 8.43 and earlier portal settings to current web profile settings is documented at the end of this PeopleBook.

See Also

Configuring Web Profiles

Understanding Changes in Portal Configuration Settings

Understanding the Authentication Domain

The portal authentication domain is the domain in which the portal is running and across which the single signon authentication token is valid. It's specified as a web server property and is used extensively throughout the PeopleSoft Pure Internet Architecture and portal runtime systems. An authentication domain is expressed as a string that completes the domain portion of an HTTP address, for example, .peoplesoft.com.

Note. The leading period is required. The correct string is, for example, .peoplesoft.com, and not peoplesoft.com.

The authentication domain supports the following functionality:

• Cross-frame JavaScript updates between the PeopleSoft Pure Internet Architecture and the portal.

  Failure to set the authentication domain correctly for the portal and PeopleSoft Pure Internet Architecture applications causes JavaScript security errors to appear in the browser when PeopleSoft Pure Internet Architecture pages are accessed through a portal frame-based template. (The default template through which all PeopleSoft Pure Internet Architecture pages are displayed is frame-based.) The authentication domain must be set for both the portal web server and other PeopleSoft content web servers.

• PeopleCode global variable sharing between components on the homepage and components within a frame.

  Failure to set the authentication domain correctly for the portal and PeopleSoft Pure Internet Architecture applications that use different web servers causes a new, incompatible session to be created on the PeopleSoft Pure Internet Architecture web server when the user accesses a PeopleSoft Pure Internet Architecture component through a frame-based template.

• Single signon functionality between PeopleSoft applications.

  Failure to specify the authentication domain correctly prevents the PeopleSoft authentication cookie from being passed to the target PeopleSoft application and forces the target system to reauthenticate the user.

• Cookie sharing between the portal and third-party web applications.

  If cookies need to be shared between web applications, then each web application must be accessed over a common domain name.

  To share cookies, specify the authentication domain as the Cookies Passed to Server (forwarding domain ) property in the portal's web profile. You specify this property on the web Profile Configuration - Cookie Rules page.

  See Configuring Cookie Rules.

Base-Level and Extended Authentication Domains

You can define the portal authentication domain as a base-level authentication domain and as an extended authentication domain.

You define the base-level authentication domain during the PeopleSoft Pure Internet Architecture setup. This domain is stored as part of your web server configuration. It enables PeopleCode global variable sharing, which is required for initial access to the portal. The portal uses the base-level domain if you don't define an extended authentication domain.

Important! You must supply a base-level authentication domain at setup for every PeopleSoft application with which the portal interacts. This value is stored on each application's web server and must be identical for each application.

See the PeopleTools 8.45 installation guide for your database platform.

You can define an optional extended authentication domain in your portal's web profile. An extended authentication domain overrides, but must be compatible with, the base-level authentication domain. For example, if you entered .customer.com during the PeopleSoft Pure Internet Architecture setup, only values such as .enterprise.customer.com and .individual.customer.com are valid.

Note. If you defined a base-level or extended authentication domain, you must use it in all URLs that you specify in your portal. For example, if your authentication domain is .mydomain.com, then instead of using the URL http://mymachine:8080/pshome/signon.html, you must use the URL http://mymachine.mydomain.com:8080/pshome/signon.html.

You specify the extended authentication domain on the Web Profile Configuration - General page.

See Configuring General Portal Properties.

An Example of Multiple Applications on a Portal

In the following example, the CRM and HRMS web profiles need to be defined with Domain Name Server (DNS) names that include the same authentication domain as the DNS name of the portal web server. They also each need the Authentication Domain property in their web profiles set to this value.

Example of the portal interacting with several different PeopleSoft applications

Web servers that don't have the same server domain as the portal (such as sales.i) can still be used to serve content to the portal. However, cookies set by the portal are not forwarded to these servers. The sales.i server in the example can provide pages and applications to the portal, but it cannot host a PeopleSoft application that supports single signon functionality with the portal.

See Also

Working with BEA WebLogic

Working with IBM WebSphere

Configuring Web Profiles

This section provides an overview of web profiles and discusses how to:

• Configure general portal properties.

• Configure portal security.

• Configure virtual addressing.

• Configure cookie rules.

• Configure caching.

• Configure trace and debug options.

• Configure look and feel.

• Configure custom properties.

• Viewing web profile histories.

Understanding Web Profiles

A web profile is a named group of configuration property settings that the portal applies throughout your PeopleSoft system to control all portal-related behavior. The following web profiles are predefined and delivered with the PeopleTools base portal:

• DEV

  The DEV web profile provides basic portal functionality for development, including trace and debug settings that are appropriate for development.

• TEST

  The TEST web profile uses the same settings as the DEV web profile, except that fewer trace and debug properties are enabled.

• PROD

  The PROD web profile uses the settings that are most commonly needed in a production environment that authenticates users.

• KIOSK

  The KIOSK web profile uses the same settings as the PROD web profile, except that public user access is enabled for the Guest user, and all options for storing caching or persistent cookies on the browser are disabled.

Additional web profiles may be delivered as part of PeopleSoft Enterprise Portal or an application portal pack. You can modify the property settings of any web profile by using the Web Profile Configuration component (WEB_PROFILE), which includes pages for these types of properties:

• General

• Portal security

• Virtual addressing

• Cookie rule

• Caching

• Debug options

• Look and feel

Specifying an Initial Web Profile

As you perform the PeopleSoft Pure Internet Architecture setup procedure for your system, you're prompted to specify which web profile to apply to your portal. You're also prompted for an existing user ID and password. This information is saved in encrypted form where the portal servlet can use it to gain secure access to the web profile.

The default web profile is DEV.

The default web profile user ID and password are both PTWEBSERVER.

The PTWEBSERVER account provides the portal servlet with minimal security access, sufficient only to launch the portal environment, but without access to any pages or other PeopleSoft Pure Internet Architecture objects. This account uses the PTPT1500 permission list, which is set to never time out, and provides necessary access for 24 hours a day, seven days a week.

Note. Your PeopleSoft application might be delivered with the account that you specify here locked. You must unlock it before you can access and configure the web profile, or you receive an error message about incorrect site configuration on the sign-in page.

You can unlock the web profile account by clearing the Account Locked Out check box on the User Profile - General page. You can alternatively issue the following SQL command against your database (this example uses the PTWEBSERVER account):

update PSOPRDEFN set ACCTLOCK=0 where OPRID='PTWEBSERVER'

See Setting General User Profile Attributes.

You can specify any of the delivered profiles, or you can enter a different profile name. In that case, the portal is set up to use a profile by that name. If a profile by the name that you specify doesn't exist in the database, internal default settings are used until you sign in to the portal and create a profile with that name. The portal then automatically configures itself according to those settings.

As long as there's no profile by the name that you specified during the PeopleSoft Pure Internet Architecture setup, the internal default settings remain in effect, which is indicated on the site's sign-in page. When the site is in this mode, every browser request triggers an attempt to load the named profile. Therefore, you shouldn't use the site for extended periods like this.

Once you complete the PeopleSoft Pure Internet Architecture setup, you can then use the Web Profile Configuration component to modify the properties to reflect your settings.

Note. The default internal settings are not the same as the DEV profile. Don't modify any of the delivered profiles, so that you always have access to unmodified reference versions. You can make a copy of any profile and modify it, or you can define a new profile instead.

Changing the Web Profile After the PeopleSoft Pure Internet Architecture Setup

After the PeopleSoft Pure Internet Architecture setup, to select a different web profile, you must edit the text file that stores this information, called configuration.properties. Each PeopleSoft portal that you set up has its own copy of configuration.properties, located in this directory:

PS_HOME\webserv\peoplesoft\applications\peoplesoft\PORTAL\WEB-INF\psftdocs\sitename

The configuration.properties file includes these properties:

• WebProfile

  Change the value of this property to the name of the web profile that you want to apply to the portal, for example, WebProfile=MYPROFILE.

• WebUserId and WebPassword

  You can specify a different user ID and password for the portal servlet to use to access the web profile, but you must encrypt the password by using a Java encryption utility that you launch from a provided script called PSCipher.

  To encrypt the user ID or password:

  1. At a command prompt, change to the location of the encryption script file:

     PS_HOME\webserv\peoplesoft

  2. On a UNIX machine, change the PSCipher.sh script file permissions so you can run it.

  3. Run the script file with your password as an argument. For example:

     pscipher MYPASSWORD

     The utility returns the encrypted password as a string. For example:

     VOBN5KcQZMg=

  4. Copy the encrypted string and paste it into the configuration.properties file, for example:

     WebPassword=VOBN5KcQZMg=

     Important! Make sure that the entire encrypted string, (including all symbol characters), is copied.

After you save the configuration.properties file, restart your web server and the new profile takes effect.

See Also

Using the integrationGateway.properties File

Pages Used to Configure Web Profiles

Configuring General Portal Properties

Access the Web Profile Configuration - General page.

Save As	Click to save a copy of the current web profile under a new name. On the Save Web Profile As page, enter a new profile name and click OK. Use to modify one of the profiles that is delivered with your PeopleSoft application.
View History	Click to access the Web Profile History search page in a new browser window.
Authentication Domain	Enter the name of the extended authentication domain in which the portal is running, starting with a leading period. This value overrides, but must be compatible with, the base-level authentication domain. For example, if you entered .customer.com during the PeopleSoft Pure Internet Architecture setup, only values such as .enterprise.customer.com and .individual.customer.com are valid. An authentication domain is required for a variety of portal functions. For example, if a cookie is shared on web servers foo.peoplesoft.com and bar.peoplesoft.com, you must specify an authentication domain of .peoplesoft.com. This field requires a value if you specified a default addressing server name on the Web Profile Configuration - Virtual Addressing page. You must qualify that server name with this domain name. The default value of the authentication domain is the one that you specified during the PeopleSoft Pure Internet Architecture setup. That value is stored as the web server's session cookie domain and kept in an internal web server file. For BEA WebLogic, that file is weblogic.xml. The preferred method for changing that value is to rerun the website setup. Note. The value that you enter in this field is automatically forced to lowercase.
Help URL	Specify the URL that is needed to link to the correct location in your HTML PeopleBooks. When users click the Help button, the appropriate context-sensitive PeopleSoft documentation should appear. To remove the help link, leave this value blank, and users won't see a Help link on the application page. Construct the URL like this: http://helpwebserver:port/productline/f1search.htm? ContextID=%CONTEXT_ID%&LangCD=%LANG_CD% For example: http://myhelpwebserver:8080/htmldoc/f1search.htm?ContextID=%CONTEXT_ID%&LangCD=%LANG_CD% Note. This setting applies only to browser access. It does not apply to users connecting in the Microsoft Windows environment by using PeopleSoft Application Designer and other development tools. You can find information about configuring Microsoft Windows-based context sensitive help in the PeopleTools installation documentation.
Compress Responses	Select to enable compression in the communication between the web server and the browser. Gzip and Compress protocols are supported. This check box is selected by default.
Compress Response References	Select to enable compression of cache files that are delivered from the web server to the user's browser. Only cache files with the Multipurpose Internet Mail Extensions (MIME) types that are specified in the Compress MIME Types text box are compressed. Gzip and Compress protocols are supported. This check box is cleared by default.
Compress MIME Types	Specify the MIME types of the cache files to be compressed as a comma-separated string. This field is available only if you selected the Compress Response References check box. The default value is application/x-javascript,text/javascript,text/css,text/html.
Compress Query	This property applies to browser requests in which the content type section of the URL is /q/, indicating a query. Select to enable compression of query responses to the browser. This check box is selected by default.
Save Confirmation Display Time	Specify in milliseconds how long the save_confirm image should appear for the user if the save confirm personalization option is enabled. The default value is 3000 milliseconds (3 seconds).
Enable Processing Message	Select to enable processing notification while the system processes a request. This check box is selected by default.
Enable New Window	Select to enable the New Window link that users can click to open a new application window. This check box is selected by default.
Enable PPM Agent (enable PeopleSoft Performance Monitor agent)	Select to activate the PeopleSoft Performance Monitor agent for this portal. The performance monitoring system has agents and monitors. An agent captures units of data (PMUs), and a monitor views and analyzes agent flows. This check box controls whether the agent is active on sites that use this profile. This check box is selected by default.
PPM Monitor Buffer Size (PeopleSoft Performance Monitor buffer size)	Specify the maximum size, in kilobytes (KB), of the Monitor Server buffer. Data is discarded once this limit is reached. This field is available only when Enable PPM Agent is selected. The default value is 51200 KB (50 megabytes).
Single Thread Netscape	Select to indicate that requests from a Netscape browser should be single-threaded to prevent crashes. Older versions of Netscape browsers had problems with multithreading responses and would crash. Select this check box if your users are using older versions of Netscape browsers and are experiencing browser crashes. This check box is cleared by default. When selected, the Single Thread Delay option appears.
Single Thread Delay	Specify a delay, in milliseconds, for single-threaded Netscape requests. This field is available only when Single Thread Netscape is selected. The default value is 1000 milliseconds (one second).
Non-standard Base Path	In the rare circumstance that you receive an error message that the base physical path has not been set, you must enter the location of the directory that contains the signon.html file for your application. This field is blank by default.

See Viewing Web Profile Histories, Understanding the Authentication Domain, Configuring Caching, Configuring Virtual Addressing, Working with Performance Monitor Web Profile Properties.

See the PeopleTools 8.45 installation guide for your database platform.

Reports

See Also

AuthTokenDomain

Working with BEA WebLogic

Working with IBM WebSphere

Configuring Portal Security

Access the Web Profile Configuration - Security page.

Days to Autofill User ID	If enabled, the system caches the user ID and automatically inserts it on the sign-in page. This a convenience for users. This feature is implemented through the use of a stored cookie on the browser. The default value is 7 days. Specify a value of 0 to disable this feature. Use 0 in a public area or kiosk situation, or if your security policy doesn't allow cookies stored on the browser.
View File Time to Live	Specify, in seconds, how long the portal should wait after sending a file attachment to a user's browser before removing that file from the web server storage. If this value is 0 then a dynamic algorithm is used based on the file size and the assumption that the user has a 56K bits-per-second modem. The default value is 0.
PIA use HTTP Same Server (PeopleSoft Pure Internet Architecture use HTTP same server)	Select to indicate that the portal should use the HTTP protocol instead of HTTPS for requests that are issued by the portal for content that is hosted on the same server as the portal servlet. Setting this property is necessary when the portal web server 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, or between different sites that are on the same web server. You can also use this property to improve the performance of homepage pagelets that are provided by the PeopleSoft Pure Internet Architecture servlet that run on the same web server as the portal, and from which the web server receives SSL requests. That is, SSL has not been terminated by a device in front of the web server. You must also specify the default addressing protocol and port on the Web Profile Configuration - Virtual Addressing page. See Using SSL Accelerators.
Allow Unregistered Content	Select to instruct the portal to serve both registered and unregistered content. The portal generally allows any external content links to be wrapped with the portal header and navigation frames. Turning this option off will prevent explicitly registered content references from being displayed in the portal. This check box is selected by default.

SSL

Authenticated Users

See Setting General Permissions.

Public Users

Web Server Jolt Settings

XML Link

See Also

Improving Same-Server Performance Under SSL

Working with BEA WebLogic

Configuring Virtual Addressing

Access the Web Profile Configuration - Virtual Addressing page.

Generate Relative URLs

Select to generate relative URLs. This setting is for use with proxy server implementations. This check box is selected by default.

Default Addressing

Reverse Proxy Server List

Use this grid to specify the reverse proxy servers through which the portal can expect to retrieve content. External content that is retrieved from these sources that contains relative references is rewritten by the portal to contain relative references instead of absolute references to preserve reverse proxy server requirements.

For each reverse proxy server on the list, you specify:

• The protocol to use.

• The server's host or machine name.

• The server's HTTP port number.

• The server's HTTPS port number.

Configuring Cookie Rules

Access the Web Profile Configuration - Cookie Rules page.

This page defines rules that determine how the portal passes cookies to servers in the same domain.

BEA WebLogic and IBM WebSphere web servers use browser cookies (containing the server path and domain) to establish session identity. These cookies have a default name that's used to retrieve the cookie on each request to the web server. In an environment where multiple web servers are in use with the portal, it is necessary to define unique session cookie names between web servers to prevent one cookie from overwriting another cookie of the same name set by a different web server. The path or domain of the cookie must be different to prevent overwriting.

Note. Use the first three fields to specify patterns to match, where the asterisk ( * ) is treated as a wildcard, matching zero or more characters.

The portal knows its own domain (from the authentication domain), and the first default rule instructs it to pass portal servlet cookies to any server in the same domain, over both secure and insecure connections. All other cookies can continue to be passed to any server on any domain.

Configuring Caching

Access the Web Profile Configuration - Caching page.

On the Browser

See Implementing Homepage Caching, Implementing PeopleSoft Page Caching.

Browsers

Use this grid to identify the browsers that you don't want to cache the homepage. For each browser make, model, and version, supply the identifying user agent ID and clear the Cache Home Page check box. To re-enable caching for a listed browser, select the browser's Cache Home Page check box.

Any browser that is not listed caches the homepage if the global Cache Homepage check box is selected.

Note. If the global Cache Homepage check box is cleared, you can't enable homepage caching for individual browsers.

See Implementing Homepage Caching.

On the Web Server

See Implementing Target Content Caching, Implementing Metadata Caching, Implementing Proxied JavaScript Caching, Administering Web Server-Based Navigation Caching.

Directories

Configuring Trace and Debug Options

Access the Web Profile Configuration - Debugging page.

Trace Monitoring Server	Select to have the PeopleSoft Performance Monitor and PPMI servlets write debug information to the web server log. This check box is cleared by default. Note. This feature is not an agent trace. For an agent trace use Trace PPM Agent.
Trace PPM Agent	Select to enable PeopleSoft Performance Monitor tracing on performance agents. This check box is cleared by default.
Show Connection Information	Select to include the database name, application server address, web server, and user ID information in the HTML that is generated for an application information page. Press Ctrl+J to view such system information for orientation and troubleshooting purposes.   Note. Some of the information that is displayed may not be suitable for end users.
Show Trace Link at Signon	Select to display a URL link at sign-in. The link opens a page for setting trace parameters.
Show Layout	Select to apply border and color attributes in a table layout for pages. This enables developers to see the position of PeopleSoft Application Designer objects in HTML.
Show Overlapping Fields	Select to include comments in generated HTML pages that may help in diagnosing page layout problems, such as fields overlapping other fields.
Show StyleSheet Inline HTML	Select to insert the page's stylesheet into its generated HTML.
Show JavaScript Inline HTML	Select to display all the JavaScript functions that are used for processing in the generated HTML page.
Generate HTML for Testing	Select to alter the generated HTML to assist with testing and troubleshooting. For example, this option provides additional white space and comments on the page to aid readability. Also, it includes additional name attributes for reference from SQA robot scripts.
Write Dump File	Select to have the system write a log file to the web server if a BEA Jolt exception error occurs.
Create File from PIA HTML Page (create file from PeopleSoft Pure Internet Architecture HTML page)	Select to view and debug the source HTML that the application server generates. The system saves each generated page as PS_HOME\appserv\domain\LOGS\client\element\N.html. The variables in the name are: Domain: The name of the application server domain. Client:The name of the machine or Internet Protocol (IP) address where the browser is running. Element: The name of the process or object that generates the HTML (query name for query, program name for iScripts, and so on). N: The state number for the generated page. Warning! Use this tracing feature only for troubleshooting and testing. Enabling this feature generates numerous directories and files on the application server, which significantly affects performance. Use it for short periods, preferably only for a single-user test scenario. Never enable it on a production website.

See Configuring Custom Properties, Working with Performance Monitor Web Profile Properties.

Configuring Look and Feel

Access the Web Profile Configuration - Look and Feel page.

Start Page

Expire Page

See Configuring Portal Security, Configuring Caching.

Error Pages

Because your PeopleSoft portal can aggregate its content from many different sources, errors can occur for a variety of reasons. An error might occur if:

• A content server is down.

• An invalid URL is specified.

• A portal node from which content is being requested is inactive.

• A portal node fails to deliver requested content within the timeout interval that you specify by using the PSTIMEOUT content reference attribute.

See Configuring Pagelet Time-outs.

For practical purposes, all of these reasons result in the requested content being unavailable.

The values that you specify for the pagelet error page, portal target error page, and portal detail error page are the names of HTML pages that present customizable, translatable error messages. The default pages are delivered with the PeopleSoft system and provide useful error messages without any modification.

You can use the delivered error pages, modify them, or create your own. You can choose additional error message information to be displayed by using bind-type variables of two types in your error pages:

• Numeric message variables

  These map to strings that are predefined in the following file:

  PS_HOME\webserv\peoplesoft\applications\peoplesoft\PORTAL\WEB-INF\psftdocs\sitename\text.properties

  For example, the numeric variable 5006 maps to the phrase “The portal was unable to retrieve the page you are looking for.”

• Session variables

  These map to system information that depends on the current page and activity.

  Session variables have values that are dynamically resolved by the portal engine at runtime. Available session variables include:

  • ErrorTitle

  • ErrorDescription

  • ErrorURL

  • AccessedURL

  • OriginalURL

  • TargetPage

  • StackTrace

  • DetailError

    DetailError is the name of the page that is specified by the Portal Detail Error Page field. This can be used to specify a link target.

To invoke a numeric or session variable, you insert it between the strings <%= and %> in your HTML. For example: <%=5009%> or <%=ErrorDescription%>. Examine the delivered error pages for examples of how to use the numeric and session variables within your HTML.

Other Pages

See Configuring General Portal Properties.

Signon/Logout Pages

Password

(Optional) Language Support

Specify additional mappings from International Organization for Standardization (ISO) locale codes to PeopleSoft language codes, using one line per entry.

The PeopleSoft system uses proprietary codes to represent user languages, and the PeopleSoft Pure Internet Architecture sign-in page appears in the PeopleSoft language corresponding to the user's browser language setting (an ISO locale code). This field enables you to provide mappings from additional ISO locale codes to PeopleSoft language codes to support a wider range of browser-specific language settings.

For example, the entry zh_HK=ZHT maps the ISO locale code zh_HK (Hong Kong Chinese) to the PeopleSoft language code ZHT (traditional Chinese), so that traditional Chinese is the default sign-in language for browsers with the preferred language set to Hong Kong Chinese.

Your PeopleSoft application is delivered with default mappings, shown on the Manage Installed Languages page. The default mappings don't require entries in this field.

See Also

Adding New Languages

Configuring Custom Properties

Access the Web Profile Configuration - Custom Properties page.

This page enables the use of web profile properties that have been added since the current release of PeopleTools was shipped, or that are needed only for backward compatibility. For each property, you enter the property name, select its validation type, and provide the appropriate property value. The validation type ensures that the property value that you enter is the correct format. The currently available custom properties are:

See Setting Up Single Signon, Viewing Monitor Servlet Diagnostics.

Viewing Web Profile Histories

Access the Web Profile History page.

Use this page to review the current portal attributes of a web server, website, and web profile, including the web server's HTTP and HTTPS listen ports, the web profile that was last loaded, and the current HTTP session's cookie name and authentication domain.

In addition, the Properties field displays the relevant settings of the web server instance at the time it was loaded by the portal.

Defining Portal Nodes

This section provides an overview of portal nodes and discusses how to:

• Set portal nodes.

• Specify the node type.

Understanding Portal Nodes

You can create and maintain a node definition in the Node Definitions component (IB_NODE). A node is defined once but can be used for multiple purposes. Several pages in the Node Definitions component are used purely for integration purposes by PeopleSoft Integration Broker. For portal purposes, define a portal by using the Node Definitions and Portal pages.

Nodes must be blank for external content references.

Note. You cannot delete a node that is in use by a content reference when the Save button is clicked. If the node is in use, the node name is not deleted.

Pages Used to Define Portal Nodes

Setting Portal Nodes

Access the Portal page.

Node Name	Displays the node name, description, and local node check box status from the Node Info page.
Tools Release	Enter the version of PeopleTools that is running.
Application Release	Enter the version of PeopleSoft applications that you are running.
Content URI Text (content uniform resource identifier text) and Portal URI Text (portal uniform resource identifier text)	Enter the uniform resource identifier (URI) of the pscontent (iclient) servlet for the node and the URI text for the portal. These values must be unique when a message node is created or updated. Important! The server name and port in these URIs must not exceed 30 characters in length. For example, http://mybiglongservername.peoplesoft.com:8080, not including the http:// prefix, is 39 characters—9 characters too long. Note. The value that you enter in these fields is automatically forced to lowercase.

See Also

Configuring Nodes

Specifying the Node Type

Access the Node Definitions page.

A node type designates the URL format for the node.

See Also

Enterprise PeopleTools 8.46 PeopleBook: Integration Broker

Configuring Nodes

Implementing Single Signon Functionality

This section provides an overview of single signon functionality and discusses how to sign in to a non-default portal.

Understanding Single Signon Functionality

PeopleSoft supports single signon functionality for use with the PeopleSoft Pure Internet Architecture. Within the context of your PeopleSoft system, single signon means that after a user has been authenticated by one PeopleSoft application server, that user can access additional PeopleSoft application servers without entering a user ID or password. Although the user is actually accessing a different application server and database, the user navigates seamlessly through the system.

The single signon authentication service is shared by all PeopleTools web services and involves these steps:

1. The first application server (node) checks the HTTP request for a PeopleSoft authentication cookie.

2. If an authentication cookie is not found, then the server returns a language-specific sign-in page.

3. The user fills out the sign-in page, entering a user ID and password.

4. The server authenticates the user based on the user ID and password.

5. A web browser cookie stores a unique access token for the user after the initial authentication.

6. An httpSession object is created for the newly authenticated session.

7. When the user connects to another PeopleSoft application server (node), the second application server uses the token in the browser cookie to reauthenticate the user without an additional sign-in process.

Because the portal integrates content from various data sources and application servers into a unified interface, you need to configure single signon functionality before deploying the portal. Users sign in once and then can navigate freely without encountering numerous sign-in pages.

However, when frame-based content is accessed across different machines, single signon functionality does not work when accessing content on another web server. If the web servers are on the same internet domain, such as .corp.peoplesoft.com, single signon functionality remains effective and a sign-in page does not appear.

See Also

PeopleSoft Sign-in

Employing Signon PeopleCode and User Exits

Setting up Digital Certificates and Single Signon

AuthTokenDomain

Signing In to a Non-Default Portal

To sign in to a portal other than the default, use a URL like this: http://portalserver/psp/ps/MY_PORTAL?cmd=login.

To create a sign-in page that signs in to a non-default portal, change signon.html like this:

<meta HTTP-EQUIV='Refresh' CONTENT='1; URL=../psp/ps/MY_PORTAL/?cmd=login'>

If you are a portal administrator and want to sign in to a database to work with PeopleTools-specific menus, replace the existing portal name with the site template name in the URL to make sure that you are administering your local PeopleTools menu and not inadvertently altering the database. Replace this:

http://../psp/ps/EMPLOYEE/

Instead, use this:

http://../psp/ps/PS_SITETEMPLATE

See Also

AuthTokenDomain

Enterprise PeopleTools 8.46 PeopleBook: Security Administration

Overriding Page Encoding

You can override the character set encoding for any page that is registered in the portal. You define a content reference attribute called PORTAL_ENCODING_OVERRIDE with a value that specifies the character set to use when processing a page. The portal servlet then overrides all other indicators for encoding, including headers and meta tags.

The standard encoding for PeopleSoft pages is UTF-8. The portal can usually determine the encoding of a page; however, if an external, non-UTF-8 page is not displayed correctly, overriding the page encoding may help.

See Also

Selecting and Configuring Character Sets and Language Input and Output

Importing Menu Groups into the Portal Registry

This section provides an overview of menu group importing and discusses how to:

• Import menu groups.

• Select components to include in portal navigation.

Understanding Menu Group Importing

The Menu Import Application Engine process (PORTAL_MENU) imports menu groups from the menu definition into a portal registry.

Important! Only System Administrators should perform this process. If the user does not have security to the menus and pages, just a folder titled Label gets created.

The process creates folders and content references that reflect the menu definition hierarchy. The folder hierarchy imported is:

Note. Use the Menu Import process to migrate custom menus only. The navigational menus that are delivered with your PeopleSoft application have already been added to the appropriate portal registry. The Menu Import process has no effect on components that are already registered. However, you can use the process to pick up additional components that are not delivered with the PeopleSoft system.

Before you use the Menu Import process, keep in mind these points:

• Object names that are assigned by the Menu Import process are autogenerated.

  If a folder name or content reference name already exists, the system appends a number to the generated object name. Consequently, you may have folder objects names such as, USE, USE1, USE2, and USE3. As a result, use the registration wizard if you plan to copy the application database registry structures into PeopleSoft Enterprise Portal. When you use the registration wizard, you can control the object naming, and you can ensure the uniqueness of object names across databases.

• If a component resides in multiple menus, the process creates a separate content reference for each menu and component combination.

• The navigation hierarchy created by the Menu Import process does not match the delivered PeopleSoft hierarchy.

  To keep the navigation consistent, consider putting all custom menus into a common menu group and generating the registry structures for that menu group. Then, once the registry structures are generated, manually move the content references to an appropriate folder in the existing navigation hierarchy.

  To create a common menu group, open the custom menu in PeopleSoft Application Designer. On the Use tab of the Menu properties dialog box, enter a unique name in the Menu Group field. After you save the menu, it is available for other menus to use.

Using the Menu Import Process with PeopleSoft Enterprise Portal

If you run the Menu Import process against multiple application databases and merge multiple registries into PeopleSoft Enterprise Portal, bar names (level three folders) can be overwritten because they frequently have duplicate names. The last folder that is copied takes precedence over all previous folders.

The autogenerated object names are based upon the current database portal registry. The Menu Import process cannot check external databases for existing object names, but it does check the current database.

If you run this process on different databases, there is a good chance that the different databases contain identical folder or content reference object names that refer to different objects. This can become problematic if you decide to copy these portal registry structures into PeopleSoft Enterprise Portal. The same-named objects overwrite each other. You might need to delete the generated folders and content references to make them unique in the future.

Use the registration wizard to register menus and components into the portal registry. Although, with the registration wizard, you must register items one by one, you can control folder and object names at the time of the import.

See Using the Registration Wizard.

Page Used to Import Menu Groups

Importing Menu Groups

Access the Menu Import page.

The Menu Import process creates content references for all components that belong to the menu group. This should be used only to migrate custom menus.

After you run the process, click the Home button in the universal navigation header and verify that the menu group has been imported into the portal registry. The new menu group should now appear along with the other folders at the top level.

Note. If the menu group does not appear, open the folder definition for the menu group and define a label for the folder.

Selecting Components to Include in Portal Navigation

During the menu import process, you can control which components are included in your portal navigation system.

To select components to include in portal navigation:

1. From PeopleSoft Application Designer, open the appropriate component.

2. Select File, Component Properties, and select the Use tab.

3. Select the Include in Navigation check box.

   After a menu import, the component is visible to users with appropriate permissions. (You can still change the permissions for any content reference after the menu import as necessary.)

   If you clear the Include in Navigation check box, the component is not imported into the portal registry during the Menu Import process. You can also set this option at the menu level.

4. Click OK.

   Changes that you make to the component in PeopleSoft Application Designer are not reflected in the portal until you do another menu import.

See Also

Using PeopleSoft Application Designer

Improving Same-Server Performance Under SSL

You might run portal and PeopleSoft Pure Internet Architecture applications over SSL connections to secure the transmissions between the browser and the web server. However, defining each homepage pagelet as an HTTPS request can cause portal performance to degrade significantly. To achieve secure transmissions between the browser and the server and to achieve acceptable homepage performance, configure the portal to use HTTP connections whenever it needs to talk to a PeopleSoft Pure Internet Architecture application that is hosted on the same server as the portal. This diagram shows this setup:

Example of the portal running under SSL by using HTTP connections to the PeopleSoft Pure Internet Architecture on the same server

This configuration requires changes to the PeopleTools web configuration properties file. It also requires that a BEA WebLogic filter be set up to block non-SSL connections, except those from the portal. The portal does not need to use HTTP or HTTPS to connect to the PeopleSoft Pure Internet Architecture servlet hosting the same website. This configuration is needed only when multiple sites are used on the same web server.

Web Profile Settings

You must tell the portal to use HTTP for all connections that it makes back to the same server on which it is hosted. To do so, modify the web profile configuration for the portal. Change these properties:

See Also

Configuring Web Profiles

Proxy Architecture and Relative URLs

Using SSL Accelerators

You can improve SSL performance by adding an SSL accelerator in front of the web server. You need to have the portal use HTTP for requests to the PeopleSoft Pure Internet Architecture to prevent the portal connection to the PeopleSoft Pure Internet Architecture from going back through the accelerator. This diagram shows this setup:

Using an SSL accelerator

The configuration is similar to that for configuring a portal running under SSL to use HTTP connections to the PeopleSoft Pure Internet Architecture on the same server; however, you must change the default port to point to the port on which the SSL accelerator is configured to listen.

Important! You must continue to configure BEA WebLogic to listen for HTTPS requests, even though the accelerator intercepts all SSL connections. Failure to do so causes the portal to function incorrectly.

Web Profile Settings

Change these properties:

See Also

Configuring Web Profiles

Working with BEA WebLogic

Working with IBM WebSphere

Using Reverse Proxy Servers

This section provides an overview of reverse proxy servers and discusses how to:

• Make reverse proxy settings.

• Issue requests by using a proxy server.

• Specify hosts that should not be proxied.

Understanding Reverse Proxy Servers

A reverse proxy server accepts requests from client browsers on behalf of another web server and then relays those requests to the web server. The reverse proxy server checks web requests and responses to ensure that they adhere to network security policies. For example, a reverse proxy server validates that a command intended for the target web server is a valid command for that server. In this diagram, the human resources PeopleSoft Pure Internet Architecture web server, corp.hr, is behind a reverse proxy server, www.pshr.com:

Example of the reverse proxy architecture

All internet requests for the human resources web server are relayed by www.pshr.com to corp.hr. The site URL routes the client to the proxy as if it were a web server. Replicated content is delivered from the proxy cache to the external client without exposing the origin server or the network residing safely behind the firewall. You can balance the load of an overtaxed web server by installing multiple instances of the web server.

Any external content must come from a node that's registered in the portal database, so that the portal servlet can look up the node name based on the URL of the content. The external content HTML is rewritten to use that proxied format.

See Also

Using Firewalls with Reverse Proxy Servers

Using Reverse Proxy Servers with SSL Accelerators

Making Reverse Proxy Settings

On the Web Profile - Virtual Addressing page, specify the reverse proxy server to use by entering it in the Reverse Proxy Server Listgrid. Include the protocol, the host name, the HTTP port, and the HTTPS port.

See Also

Configuring Virtual Addressing

Issuing Requests by Using a Proxy Server

To make a portal issue requests by using a proxy server, the proxy server settings are controlled by these Java system properties:

• http.proxyHost

• http.proxyPort

• https.proxyHost

• https.proxyPort

To use a proxy server for the HTTP protocol, set these properties:

http.proxyHost=http_proxy_server_host_name
http.proxyPort=http_proxy_server_port

To use a proxy server for the HTTPS protocol, set these properties:

https.proxyHost=https_proxy_server_host_name
https.proxyPort=https_proxy_server_port

The method for setting the Java system parameters varies by web server (BEA WebLogic or IBM WebSphere). The properties must be passed to the Java interpreter as command-line directives.

For BEA WebLogic

Alter the startWeblogic.cmd or startWeblogic.sh file. Define the properties on the command line that starts the Java Virtual Machine like this:

set PROXY=-Dhttp.proxyHost=proxyhostname -Dhttp.proxyPort=proxy_port -Dhttps.proxyHost=proxyhostname -Dhttps.proxyPort=proxy_port

%JAVA_HOME%\bin\java -ms64m -mx64m -classpath %JAVA_CLASSPATH% %PROXY% -Dweblogic.class.path=%WEBLOGIC_CLASSPATH% -Dweblogic.home=.
-Djava.security.manager -Djava.security.policy==.\weblogic.policy weblogic.Server

goto finish

For IBM WebSphere

All the Java Virtual Machine settings for IBM WebSphere are set in /WebSphere/AppServer/config/server-cfg.xml file.

Java Virtual Machine properties are embedded within the <jvmSettings> and </jvmSettings> elements.

<jvmSettings xmi:id="JavaVirtualMachine_1" classpath="${WAS_ROOT}/lib/bootstrap.jar;${WAS_ROOT}/properties;" bootClasspath=""
verboseModeClass="false" verboseModeGarbageCollection="false" verboseModeJNI="false" initialHeapSize="4" maximumHeapSize="256"
runHProf="false" hprofArguments="" debugMode="false" debugArgs="" genericCommandLineArgs="com.ibm.ws.runtime.StandardServer"
disableJIT="false">
  <systemProperties xmi:id="SystemProperty_1" name="server.root" value="${WAS_ROOT}"/>
  <systemProperties xmi:id="SystemProperty_2" name="ws.ext.dirs" value="${JAVA_HOME}/lib;${WAS_ROOT}/classes;${WAS_ROOT}/lib;${WAS_ROOT}/lib/ext;${WAS_ROOT}/web/help;${WAS_ROOT}/properties"/>
  <systemProperties xmi:id="SystemProperty_3" name="com.ibm.CORBA.ConfigURL" value="file:/${WAS_ROOT}/properties/sas.server.props"/>
  <systemProperties xmi:id="SystemProperty_4" name="HttpSessionIdReuse" value="true"/>
</jvmSettings>

Specifying Hosts That Should Not Be Proxied

If your portal implementation retrieves content from both an intranet and the internet, you might encounter a problem retrieving both internal and external content if the proxy server is not aware of the address of the intranet content. You can avoid this situation by specifying that certain hosts (such as your intranet hosts) should not be accessed through the proxy server.

For BEA WebLogic, specify the hosts not to be proxied in the HTTP_PROXY_NONPROXY_HTTPHOSTS and HTTP_PROXY_NONPROXY_HTTPSHOSTS environment variables with the setEnv.cmd (setEnv.sh in Unix) script. Refer to comments in setEnv for specific syntax.

For IBM WebSphere, specify the hosts not to be proxied in the Java system variables http.nonProxyHosts and https.nonProxyHosts in the IBM WebSphere console:

1. Access the IBM WebSphere administration console.

2. Expand Servers, Application Servers, server-name, Process Definition, Java Virtual Virtual Machine, Custom Properties.

3. Click New.

4. Add a key-value pair for each system variable.

5. Save the configuration, then log out and restart IBM WebSphere.

For either web server platform, you can list a set of patterns that should not be accessed through proxies, with each one separated by the pipe character ( | ). This example shows a setting that makes all HTTP connections to the eng domain bypass the proxy settings:

*.eng|*.eng.peoplesoft.com

Using Firewalls with Reverse Proxy Servers

You can set up a buffer zone in front of the portal web server to prevent unauthorized access to the portal web server and create a more secure environment. A buffer zone is typically configured with a firewall that allows access to a reverse proxy server, which relays incoming requests through a second firewall to the portal web server. This diagram shows this setup:

Firewall and reverse proxy setup

The configuration is similar to that for configuring a portal running under SSL to use HTTP connections to the PeopleSoft Pure Internet Architecture on the same server; however, you must make these adjustments in the web profile:

Hosts File Setup

The hosts file on the portal web server must have an entry that directs DNS requests for the content provider server name (the reverse proxy server in the previous example) to the portal web server, for example, 123.456.345.02. This enables the portal to make requests for content that is hosted on the same server directly without going back through the reverse proxy server.

For example:

123.456.345.02 portal.corp.com

See Also

Configuring Web Profiles

Using Reverse Proxy Servers with SSL Accelerators

You can combine an SSL accelerator with a reverse proxy server, as illustrated in this diagram:

Reverse proxy server with an SSL accelerator

The configuration is similar to that for configuring a portal running under SSL to use HTTP connections to the PeopleSoft Pure Internet Architecture on the same server; however, you must make these adjustments in the web profile

Hosts File Setup

The hosts file on the portal web server must have an entry that directs DNS requests for the content provider server name (portal.corp.com) to the portal web server, for example, 123.456.345.02. This enables the portal to make requests for content that is hosted on the same server directly without going back through the reverse proxy server.

For example:

123.456.321.02 portal.corp.com

See Also

Configuring Web Profiles

Working with BEA WebLogic

Working with IBM WebSphere

Applying Load Balancing

You can apply load balancing to a portal by using a hardware load-balancing solution to distribute load across multiple instances of the BEA WebLogic server on multiple web server machines. Many of today’s hardware load balancers have SSL accelerating options that you should also consider. The number and size of web server machines and the number of web server instances per machine vary and determine load-balancing requirements and hardware selection. This diagram shows a possible load-balancing setup:

Example of load balancing

The hardware load balancing solution must be configured to enable sticky sessions, which ensures that all requests from a user’s browser session are delivered to the same web server session. In the example previous diagram, if the initial request from the browser was directed to IBM WebLogic Server F, then all subsequent requests from that browser session must be directed to the same instance of IBM WebLogic.

Keep multiple web server sessions on a single machine to keep the heap size of the Java Virtual Machine manageable and to allow the Java garbage collection to work optimally.

Hosts File Configuration

The hosts file on the portal web server machines in the previous diagram—which we'll call portalws1 and portalws2—must have an entry that directs DNS requests for the portal content provider server name (portal.corp.com) to the portal web server (123.456.345.11 on portalws1). This allows the portal to request content hosted on the same server directly without going back through the load balancer.

This is an example hosts file on portalws1.corp.com:

123.456.345.11 portal.corp.com

123.456.345.11 portalws1.corp.com