Working with Oracle WebLogic

This chapter provides an overview of WebLogic and discusses how to:

• Work With the WebLogic Server Administration Console.

• Start WebLogic.

• Stop WebLogic.

• Use WebLogic Server Administration Console to Monitor PeopleSoft Sessions.

• Set Up Reverse Proxy Servers.

• Set The HTTP Session Timeout.

• Set Authentication Failure Timeout.

• Enable or Disabling HTTP Keep Alive.

• Change WebLogic User Passwords.

• Implement WebLogic SSL Keys and Certificates.

• Work With WebLogic Session Cookies.

• Secure Servlets on WebLogic.

• Adjust the JVM Heap Size.

• Determine the Service Pack Level.

• Enable HTTP Access Log.

Understanding WebLogic

You use the Oracle WebLogic Server as a web server in the PeopleSoft Internet Architecture to deploy PeopleSoft applications. The PeopleSoft Internet Architecture installation on the WebLogic Server provides these primary server configuration options.

• Single server.

  This domain configuration contains one server named PIA, and the entire PeopleSoft application is deployed to it. This configuration is intended for single user or very small scale, non-production environments.

• Multi server.

  This domain configuration contains seven unique server definitions and a WebLogic cluster, and the PeopleSoft application is split across multiple server instances on a single machine. This configuration is intended for the production environment.

• Distributed managed server.

  This option is an extension of the “Multi server” selection and installs the necessary files to boot managed servers spread across multiple machines. This option requires a “Multi server” installation to be performed to some other location that contains the configuration for this managed server.

Note. The topics related to WebLogic in this PeopleBook discuss PeopleSoft-specific subjects. Always refer to your Oracle WebLogic documentation for all general server administration information.

Working With the WebLogic Server Administration Console

The WebLogic Server Administration Console is the main utility that is used to administer and monitor the WebLogic server processes.

Note. For the sake of brevity, in this document the WebLogic Server Administration Console will be referred to as the Administration Console.

The Administration Console provides an interface to monitor and configure aspects of a PeopleSoft application from a web server perspective.

Access the Administration Console by pointing your browser to:

http://<server>:<port>/console

For example,

http://server08.us.oracle.com:80/console

Before the Administration Console opens, you will be prompted for the WebLogic system ID and password that you specified during the PeopleSoft install.

Note. The default ID is system and the default password is Passw0rd. (using a zero, not the letter "O."

The Domain Structure section enables you to navigate to a variety of interfaces related to the elements of your PeopleSoft domain.

Note. Before making any configuration modifications or performing any administrative operations, such as stopping the server, always click Lock & Edit first.

Starting WebLogic

This section discusses how to:

• Start WebLogic on Microsoft Windows.

• Start WebLogic on UNIX.

See Also

Administering a WebLogic Server Life Cycle

Starting WebLogic on Microsoft Windows

On Microsoft Windows, you can start WebLogic using:

• command prompt.

• Windows service.

Using the Command Prompt

Running WebLogic as a foreground process is beneficial if you need to monitor WebLogic in real time. To run WebLogic as a foreground process, enter one of the following commands at the command prompt in PIA_HOME\webserv\domain\bin.

Using the Windows Service

Benefits of running WebLogic as a Windows service include:

• WebLogic can automatically start when the Windows server boots.

• You can start and stop the service from a remote Windows machine.

To install the service, open the command prompt, and enter the appropriate command from your PIA_HOME\webserv\domain\bin directory:

To start WebLogic as a Windows service, you can:

• Start the service named WebLogicdomain-servername (for example, peoplesoft-PIA) by using the Services utility in the Windows Control Panel.

• Start the service from a command prompt by entering the following command:

   NET START peoplesoft-PIA

Note. If WebLogic fails to start as a service, try starting it as a foreground process to make sure there are no general issues related to the startup.

To uninstall the service, enter the following command:

uninstallNTservicePIA.cmd

Starting WebLogic on UNIX

To start PeopleSoft on UNIX execute the appropriate script in the WebLogic domain directory that the PeopleSoft install created, as in PIA_HOME/webserv/peoplesoft/bin.

When you run the above scripts, the server runs as background process.

Stopping WebLogic

You can stop Weblogic using:

• Administration Console

• command line

See Also

Administering a WebLogic Server Life Cycle

Stopping WebLogic Using the Administration Console

To stop the PeopleSoft server:

1. In the left pane of the console, expand Environment, and select Servers.

2. In the Summary of Servers table, click the name of the server that you want to shut down.

3. Select the Control tab, and then the Start/Stop tab.

4. From the Shutdown drop-down menu, select one of the following options:

   • When work completes: This command initiates a graceful shutdown, which gives WebLogic Server subsystems time to complete application processing currently in progress.

   • Force Shutdown now: This command initiates a forced shutdown, in which the server instructs subsystems to immediately drop current requests.

5. Click Yes to confirm and shut down the server.

   Note. If you shut down the Administration Server, the Administration Console is no longer active.

Stopping WebLogic Using the Command Line

To stop WebLogic using the command line, enter the appropriate command.

If WebLogic is running as a Windows service you can also stop the service in Windows Control Panel or using the NET STOP command.

Using WebLogic Server Administration Console to Monitor PeopleSoft Sessions

The Administration Console can display a list of established HTTP sessions for an instance of the WebLogic Server. Session Monitoring is automatically enabled for WebLogic. These instructions describe how to monitor the single server configuration of PIA in a test environment.

When in a production environment, note that a multi server configuration would be used to perform these steps to the server instance that you intend to monitor, such as PIA1 or PIA2, or both.

1. Start the PIA server.

2. Log on to PeopleSoft.

   If possible, log on from different workstations using different PeopleSoft IDs. For the purpose of this test, do not log off.

3. Log on to the WebLogic Server Administrative Console.

4. Monitor established HTTP sessions for the PORTAL web application.

   On the left, use the following navigation to view the list of established HTTP sessions for the PORTAL web application:

   1. Click Deployments, and view the deployment list in the right hand window.

   2. Click PeopleSoft.

   3. Select the Control tab.

   4. Select the PORTAL application module, where the context root of the module is '/'.

   5. Select the Monitoring tab.

   6. Select the Sessions tab.

Note. You can customize the list of fields that you want to monitor using the Customize this table link.

Note. An established HTTP session remains on the web server until the client logs out of PeopleSoft or until the user's HTTP session times out. Closing the browser does not log out a PeopleSoft user. As a result, when a user closes the browser without logging out of the PeopleSoft session, the corresponding HTTP session remains on the web server until it times out. HTTP session timeouts are controlled by the site's PeopleSoft web profile.

See Also

Tuning Performance and Monitoring Resources

Setting Up Reverse Proxy Servers

This section provides an overview and discusses how to:

• Configure Microsoft Internet Information Server (IIS) as an RPS.

• Configure WebLogic as an RPS.

• Configure Sun Java System Web Server as an RPS.

• Configure Apache HTTP as an RPS.

Understanding Reverse Proxy Servers For PeopleSoft Implementations

PeopleSoft applications support the use of reverse proxy servers (RPS) with WebLogic. When using an RPS, the RPS provides the URL to which the browsers connect, but another web server handles the actual transaction processing. Implementing the use of RPS servers provides an additional protective layer between the content server and the internet.

A reverse proxy is a server that appears to outside clients to be the content server. It relays requests from outside the firewall to servers behind the firewall, and delivers retrieved content back to the client. A firewall rule allows access only to the proxy server, so that the content servers are protected. The proxy server changes URLs listed in the headers of any messages generated by the content servers, so that external clients are given no information about the servers behind the firewall. No configuration of clients is necessary with a reverse proxy (the client makes requests for content in the name-space of the reverse proxy). The reverse proxy decides where to send the requests, and returns the content as if it was the origin server.

Configuring Microsoft IIS as an RPS

This section describes how to proxy content to a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA, PIA1, PIA2, and so on.

Microsoft Internet Information Server (IIS) can be configured as a reverse proxy server (RPS) to one or more WebLogic Server instances. Multiple instances can be independent instances or grouped into a cluster. When you use a reverse proxy, any URL that would be used to access your PeopleSoft application (even URLs that are stored in the database) would point to the reverse proxy, and not to the WebLogic Server.

These instructions are based on a logical separation of WebLogic Server and Microsoft IIS, where both web servers are installed on the same machine. If your configuration has WebLogic Server and Microsoft IIS on separate machines, you must perform these additional tasks:

• From the WebLogic server, copy WL_HOME\server\plugin\win\32\iisproxy.dll or WL_HOME\server\plugin\win\64\iisproxy.dll to c:\inetpub on your Microsoft IIS server.

• From the WebLogic server, copy WL_HOME\server\plugin\win\32\iisforward.dll or WL_HOME\server\plugin\win\64\iisforward.dll to c:\inetpub on your Microsoft IIS server.

• In the following procedure, change any reference of WL_HOME\server\plugin\win\32\ or WL_HOME\server\plugin\win\64\ to c:\inetpub.

Note. In these instructions, make the appropriate adjustments for your server's architecture (32–bit or 64–bit).

To set up a Microsoft IIS RPS:

1. Access your installed Microsoft IIS configuration.

   On a Microsoft Windows server, select Start, Programs, Administrative Tools, Internet Services Manager.

2. Open the Default Web Site properties

   Expand your list of available servers, right click the Default Web Site and select Properties.

3. Add an ISAPI filter.

   • Select the ISAPI Filters tab, and click Add to define a new filter.

   • Enter IISFORWARD for the filter name.

   • Enter WL_HOME\server\plugin\win\32\iisforward.dll or WL_HOME\server\plugin\win\64\iisproxy.dll for the executable.

4. Define a new application extension mapping.

   • Select the Home Directory tab then click Configuration.

   • Click Add on the App Mapping tab to define a new application mapping.

   • Enter WL_HOME\server\plugin\win\32\iisproxy.dll or WL_HOME\server\plugin\win\64\iisproxy.dll for the executable.

   • Enter .wlforward for the extension.

   • For Verbs, enter All Verbs (or at a minimum, GET and POST).

5. Create the IIS-Plugin configuration file.

   Create WL_HOME\server\plugin\win\32\iisproxy.ini or WL_HOME\server\plugin\win\64\iisproxy.ini, containing the following lines and setting the values appropriately.

   #
   #For a list of available parameters see
   #http://edocs.bea.com/wls/docs103/plugins/index.html
   #
   WebLogicHost=<hostname or IP of weblogic server to forward requests to>
   WebLogicPort=<HTTP port of weblogic server to forward requests to>
   DebugConfigInfo=OFF
   Debug=OFF
   #
   #To proxy all IIS directed requests to WebLogic set "WlForwardPath=/"
   #To selectively proxy only PeopleSoft requests to WebLogic set "WlForwardPath="to 
   #the list of PeopleSoft sites to proxy. 
   #e.g. To proxy requests for only 'ps' and 'crm' set WlForwardPath to the following;
   #WlForwardPath=*/ps/*,*/crm/*
   WlForwardPath=/
   #
   #If you have specified an AuthTokenDomain during your PIA installation, 
   #you must set the cookieName for your reverse proxy.
   #WLCookieName=<CookieName as specified on weblogic in PORTAL webapps's⇒
    weblogic.xml>
   

6. Restart Microsoft IIS.

   Restart the two Windows services, IIS Admin Service and World Wide Web Publishing Service by using the Services utility in the Control Panel or by issuing the following three commands at a command prompt:

   NET STOP IISADMIN /Y
   NET START IISADMIN
   NET START W3SVC

7. Start the WebLogic server.

   See Starting WebLogic.

   See Stopping WebLogic.

8. Test your configuration by accessing the Microsoft IIS server by using the URL for your site.

   For example, http://IIS_server:port/ps/signon.html.

   Note. To connect to Microsoft IIS by using HTTPS, you must install digital certificates on the Microsoft IIS server.

See Also

Installing and Configuring the Microsoft IIS Plug-In: http://e-docs.bea.com/wls/docs103/plugins/isapi.html

Parameters for Web Server Plug-Ins: http://e-docs.bea.com/wls/docs103/plugins/plugin_params.html#wp1143055

Configuring Microsoft IIS 7.0 as an RPS

This section describes how to proxy content to a single server configuration of PIA. In a production environment, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA, PIA1, PIA2, and so on.

Microsoft Internet Information Server (IIS) can be configured as a reverse proxy server (RPS) for one or more WebLogic Server instances. Multiple instances can either be independent instances, or grouped into a cluster. When using a reverse proxy, all URLs that are used to access your PeopleSoft application (even URLs that are stored in the database), need to point to the reverse proxy, and not to the WebLogic server.

Oracle only supports IIS 7.0 as an RPS on Windows Server 2008 x64 Standard Edition, or Enterprise Edition environments. These instructions are based on a logical separation of WebLogic Server and Microsoft IIS 7.0, where both web servers are installed on the same machine. If your configuration has WebLogic Server and Microsoft IIS on separate machines, you must perform these additional tasks:

• From the WebLogic server, copy WL_HOME\server\plugin\win\x64\iisproxy.dll to c:\inetpub, or to any other directory where an administrator has appropriate access to it on your Microsoft IIS server.

• From the WebLogic server, copy WL_HOME\server\plugin\win\x64\iisforward.dll to c:\inetpub, or to any other directory where an administrator has appropriate access to it on your Microsoft IIS server.

• In the procedures described below, change any reference to: WL_HOME\server\plugin\win\x64\, to c:\inetpub\, or to the other directory where you copied the two files mentioned above.

Note. In these instructions, make the appropriate adjustments for your server's architecture (32–bit or 64–bit).

Configuring the Microsoft IIS 7.0 RPS

To set up a Microsoft IIS 7.0 RPS:

1. Access your installed Microsoft IIS 7.0 configuration.

   On a Microsoft Windows server, select Start, Programs, Administrative Tools, Internet Information Service (IIS) Manager.

2. Add a JSP Script Mapping.

   1. After selecting the Default Web Site in the lefthand pane, locate the Handler Mappings icon in the panel to the right. Right click on Handler Mappings and select “Open Feature”.

   2. Right click in the new window and select Add Script Map…

   3. Enter *.jsp as the Request path.

   4. Browse to the iisproxy.dll file mentioned earlier, and add it as the executable. Name it: JSP.

   5. Click on the Request Restrictions… button, and uncheck the box titled Invoke handler only if the request is mapped to.

   6. When finished, click OK.

   7. A warning message will appear, asking you if you want to allow the ISAPI extension. Select Yes to continue.

3. Add a WLFORWARD Script Mapping.

   1. In the same Handler Mappings panel, right click and again select Add Script Map…

   2. Enter *.wlforward as the Request path

   3. Browse to the same iisproxy.dll file mentioned earlier, and add it as the executable. Name it: WLFORWARD.

   4. Click on the Request Restrictions… button, and uncheck the box titled Invoke handler only if the request is mapped to.

   5. When finished, click OK.

   6. A warning message will appear, asking you if you want to allow the ISAPI extension. Select Yes to continue.

4. Add an ISAPI filter.

   1. On the Default Web Site, locate the ISAPI Filters icon.

   2. Right click on this icon, and select Open Feature.

   3. Right click in the new window and select Add…

   4. Enter WLFORWARD as the Filter name.

   5. Browse to the iiforward.dll file and add it as the executable.

   6. When finished, click OK.

5. Provide necessary restrictions to the entire IIS:

   1. Select the root node with your hostname in the lefthand pane.

   2. Locate the ISAPI and CGI Restrictions icon on the right.

   3. Right click on the ISAPI and CGI Restrictions icon and select Open Feature.

   4. Right click and select Edit Feature Settings…

   5. Ensure that both Allow unspecified CGI modules, and Allow unspecified ISAPI modules are checked.

   6. When finished, click OK.

6. Create an IIS Plugin configuration file:

   Create a WL_HOME\server\plugin\win\x64\iisproxy.ini file which contains the following lines. (The file should be placed in the same directory as the two plug-in DLL files that were mentioned at the top of this document.) Set the values appropriately for your environment.

   #For a list of all available parameters see:
   #http://download.oracle.com/docs/cd/E12840_01/wls/docs103/plugins/plugin_⇒
   params.html#wp1143049
   
   #
   WebLogicHost=<hostname or IP of the WebLogic server to forward requests to>
   WebLogicPort=<HTTP port of WebLogic server to forward requests to>
   DebugConfigInfo=OFF
   Debug=OFF
   #
   
   #To proxy all IIS directed requests to WebLogic, set "WlForwardPath=/"
   #
   #To selectively proxy only PeopleSoft requests to WebLogic, set "WlForwardPath="⇒
    to 
   #the list of PeopleSoft sites to proxy. 
   #e.g. To proxy requests for only the ‘ps’ and ‘crm’ sites, set WlForwardPath to⇒
    the following:
   #WlForwardPath=*/ps/*,*/crm/*
   WlForwardPath=/
   #
   #If you have specified an AuthTokenDomain during your PIA installation, 
   #you must set the cookieName for your reverse proxy.
   WLCookieName=<CookieName as specified on WebLogic in PORTAL webapps’s weblogic.xml>
   

7. Restart Microsoft IIS:

   Restart the two Windows services: IIS Admin Service, and World Wide Web Publishing Service, by using the Services utility in the Control Panel, or by issuing the following three commands at a command prompt:

   NET STOP IISADMIN /Y
                   
   NET START IISADMIN
                   
   NET START W3SVC
   

   Or, restart only the default website by right clicking on Default Web Site, and selecting: Manage Web Site, Restart.

8. Start the WebLogic server.

9. Test your configuration by accessing the Microsoft IIS server by using the URL for your site.

   For example, http://IIS_server:port/ps/signon.html.

   Note. To connect to Microsoft IIS by using HTTPS, you must install digital certificates on the Microsoft IIS server.

See http://download.oracle.com/docs/cd/E15523_01/web.1111/e14395/isapi.htm#BGBFJAEJ

See http://download.oracle.com/docs/cd/E12840_01/wls/docs103/plugins/plugin_params.html#wp1143049

Configuring WebLogic as an RPS

This section discusses how to configure a WebLogic server as an RPS.

Note. Using WebLogic as a reverse proxy server is not recommended in a production environment.

Creating the RPS

To create an RPS, select Multi Server Domain as the configuration during the PeopleSoft Internet Architecture installation. The multi server domain installation automatically defines a server named "RPS" in addition to the main PIA server. The RPS is configured to be a reverse proxy server to other managed servers.

By default, the following settings are applied to the RPS:

The default address specified for the back-end WebLogic content server assumes that it's the same machine as the one on which you're configuring the RPS, using the HttpProxyServlet application. There's no need to change this setting unless the content server is a different machine, or you enable load balancing with multiple content servers. If it's a different machine, you must change this setting to specify the correct content server. If you enable load balancing, you'll need to specify additional content servers.

Enabling Load Balancing

In addition to the HttpProxyServlet application, the PIA setup also defines an HttpClusterServlet application in your WebLogic configuration, which by default isn't active. The primary difference between the two applications is that for a given HTTP request, HttpProxyServlet can proxy content only from a single back-end content server, whereas HttpClusterServlet can proxy content from multiple back-end content servers, all of which serve the same content. This enables the RPS to load-balance the requests across a cluster of WebLogic servers.

You can configure the RPS for load balancing by changing the default web application from HttpProxyServlet to HttpClusterServlet, which becomes active as a result.

To change the default web application:

1. Start the WebLogic server.

2. Sign in to the Administration Console.

3. In the Domain Structure tree, click Deployments.

4. Click HttpProxyServlet, and select the Targets tab.

5. Clear the RPS Server check box, click Apply, and click Activate Changes.

6. In the Domain Structure tree, click Deployments.

7. Click HttpClusterServlet, and select the Targets tab.

8. Select the RPS Server check box, and click Apply.

9. Log out of the Administrative Console.

Specifying Back-End WebLogic Content Servers

You need to specify back-end WebLogic content servers only for the currently designated default web application (HttpProxyServlet or HttpClusterServlet).

To do this, you edit the appropriate web.xml configuration file directly.

host1:http_port:https_port|
host2:http_port:https_port

Starting the RPS

To start the RPS, open a command prompt, change to PIA_HOME\webserv\weblogic_domain, and launch the following commands:

1. Open a command prompt, and change to PIA_HOME\webserv\weblogic_domain.

2. Start the WebLogic Admin Server.

   startWebLogicAdmin

3. Start the RPS server.

   startManagedWebLogic RPS

Note. You can also run the RPS as a service on Windows.

See Also

Starting WebLogic

Stopping WebLogic

“WebLogic documentation for WebLogic Proxy,” http://e-docs.bea.com/wls/docs103/plugins/http_proxy.html#wp115201

“WebLogic documentation for proxy parameters, ” http://e-docs.bea.com/wls/docs103/plugins/plugin_params.html

Configuring Sun Java System Web Server as an RPS

This section describes how to proxy content to a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA, PIA1, PIA2, and so on.

These instructions assume you have downloaded the Sun Java System Web Server from Sun.

Installing the WebLogic Plug-In

Configuring the Sun Java System Web Server as an RPS involves installing a WebLogic plug-in on the Sun Java System Web Server. The plug-in comes in the form of a set of .DLL files for Windows systems and library files for UNIX systems.

To configure Sun Java System Web Server as an RPS:

1. Locate the appropriate WebLogic plug-in files within your WebLogic installation, which are "proxy*.dll" or "proxy*.so" or "proxy*.sl".

   Note. If you are going to run your Sun web server on the same machine as WebLogic, it is recommended that you don't copy the plug-in files to your Sun web server.

   The plug-in files are located in the following location:

   WL_HOME/server/plugin/operating system/architecture

   Where:

   • WL_HOME represents the top level installation directory for your WebLogic server.

   • operating system corresponds to the operating system, such as AIX, Linux, or Windows.

   • architecture corresponds to the bit architecture of your operating system (32-bit, 64-bit).

2. Copy the appropriate WebLogic plug-in files to your Sun web server installation.

   Copy the plug-in files to:

   Sun_Home\operating system\plugins

   Where:

   • Sun_Home refers to the high-level installation location of your Sun Java System Web Server.

   • operating system refers to the operating system the Sun Java System Web Server is installed on.

3. Define the NSAPI Module.

   This step covers modifying the magnus.conf configuration file to reference the provided NSAPI module. Make sure to make a backup of it prior to modifying it.

   Open the magnus.conf file located in:

   C:\Sun_Home\server\https-machine_name.com\config

   Add the following lines to the bottom of the magnus.conf file. This instructs the Sun web server to load the native library as an NSAPI module. For Sun_Home and drive, substitute the actual location, including the drive letter of the NSAPI module you copied in at previous steps:

   Init fn="load-modules" funcs="wl-proxy,wl-init"\ shlib=<drive>:/<Sun_Home>/plugins⇒
   /proxy36.dll Init fn="wl-init"

   If you skipped Step 1 because Sun web server and WebLogic are running on the same machine, update your configuration file similar to the following:

   Init fn="load-modules" funcs="wl_proxy,wl_init"\ shlib="<drive>:/WebLogic_home⇒
   /wlserver_10.3/server/bin/proxy36.dll" Init fn="wl_init" 

4. Define which requests to be handled by the plug-in.

   The type of requests to be handled by the plug-in, and subsequently handed off to WebLogic, must be declared as part of an object definition in the magnus.conf file. A specific string in the URL, referred to as a ppath, can identify these requests.

   To proxy all requests of a single PeopleSoft Internet Architecture site, such as ps (which would be accessed as http://machine_name.com/ps/signon.html), define the following object tag in the magnus.conf file. Define this and any other object tags directly following the default object tag.

   <Object name="ps" ppath="*/ps/*">
   Service fn=wl-proxy WebLogicHost=server1\
    WebLogicPort=7001
   </Object>

   The default object tag is generally several lines long and can be identified by <Object name=default>...</Object>.

   To proxy additional sites, add subsequent object tags referencing the other site names:

   <Object name="hr" ppath="*/hr/*">
   Service fn=wl_proxy WebLogicHost=server1\
    WebLogicPort=7001
   </Object>
   

   To proxy all requests that are made to the Sun web server, create a single object tag named "peoplesoft" and set the ppath parameter to *.

5. Apply changes to the Sun web server.

   With these settings saved, access the Server Manager, as in http://localhost:8888. When prompted, click the Apply button to update the Sun web server with your changes and restart it.

6. Make sure the PIA WebLogic Server is running.

7. Confirm the configuration.

   To confirm the configuration between the WebLogic Server and the Sun web server, access PeopleSoft using the typical URL. For example,

   http://urserver.com/ps/signon.html

   If you are able to logon to PeopleSoft, your proxy plug-in installation and configuration was successful.

Working With the Sun Java System Web Server RPS Configuration

If you plan to proxy all requests for the PeopleSoft Internet Architecture through the Sun web server, you must also update any URLs that are defined in the PeopleSoft database to reference the proxy server (Sun web server), not the WebLogic server.

The magnus.conf file strictly enforces where text can be added. To avoid problems, follow these guidelines:

• Eliminate extraneous leading and trailing white space. If you must enter more characters than can be fit on one line, place a backslash (\) at the end of that line and continue typing on the following line. The backslash directly appends the end of the first line to the beginning of the following line.

• If a space is necessary between the words that end the preceding line and begin the next line, use one space, either at the end of the first line (before the backslash), or at the beginning of the second line.

• Do not split attributes across multiple lines.

The WebLogic online documentation contains a complete listing of WebLogic plug-in attributes and parameters.

See http://e-docs.bea.com/wls/docs103/plugins/plugin_params.html

Configuring Apache HTTP as an RPS

This section describes how to configure Apache to be a proxy for a single server configuration of PIA running on WebLogic. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA, PIA1, PIA2, and so on.

To configure Apache HTTP:

1. Download and install the Apache HTTP server.

   See http://www.apache.org/dist/httpd/

2. Install the Apache HTTP server plug-in.

   The installation of the Apache plug-in depends on whether you are installing the plug-in as a dynamic shared object (DSO) or a statically linked module. If you have downloaded the binary distribution of Apache, you will probably install the Apache plug-in from as a shared object. If you are in doubt as to which type, install the plug-in as a DSO. Exact instructions are available in the WebLogic documentation.

   See http://e-docs.bea.com/wls/docs103/plugins/apache.html

3. Specify the parameters that will be used by the Apache plug-in by defining them in an IfModule tag for WebLogic in the Apache httpd.conf file.

   Add this tag in the ### Section 2: 'Main' server configuration section of httpd.conf. For example, to configure the Apache to proxy all requests that it receives to a WebLogic server that is running on a machine named crm.peoplesoft.com and listening on port 7001, you would define the following tag:

   <IfModule mod_weblogic.c>
   	  WebLogicHost crm.peoplesoft.com
   	  WebLogicPort 7001
   	  MatchExpression /</IfModule>

   Sample and template configuration files are provided.

   See http://edocs.bea.com/wls/docs103/plugins/index.html

   To proxy requests to a cluster of WebLogic servers, replace the two attributes, WebLogicHost and WebLogicPort, with WebLogicCluster.

   The syntax of the WebLogicCluster is wlserver1:port,wlserver2:port.

   See The red paper posted on My Oracle Support:Clustering and High Availability for PeopleSoft

   If you specified an AuthTokenDomain during the PeopleSoft Internet Architecture installation, you must set the WLCookieName for the reverse proxy to that same value. To do so, add the WLCookieName attribute and set its value to CookieName, as specified on the WebLogic server in the PORTAL web application's weblogic.xml file in PIA_HOME\webserv\peoplesoft\applications\peoplesoft\PORTAL.war\WEB-INF\weblogic.xml.

4. Start the Apache HTTP server following the Apache usage instructions.

5. Start the WebLogic server.

6. Confirm the configuration between both the WebLogic server and Apache servers by signing onto the PeopleSoft system by using the typical URL. For example,

   http://Apachehost/ps/signon.html.

   If you can sign in to the PeopleSoft system, your installation and configuration was successful.

See Also

http://edocs.bea.com/wls/docs103/plugins/index.html

Setting The HTTP Session Timeout

PeopleSoft Internet Architecture does not use session timeout controls set on the web server.

The HTTP session timeout controls are accessible on the Security page of the web profile interface. At runtime, the session timeouts set in the current web profile override any HTTP session timeouts set on the web server.

See Configuring Portal Security.

Setting Authentication Failure Timeout

To limit the effectiveness of DOS attacks on failed authentications, you can use the psft_failtimeout Java option. Add this option in the setEnv script and assign a value in seconds. By setting the value to 60 seconds, for example, you override the default session timeout of 120 seconds (two minutes) when a user authentication fails or when a user is not yet authenticated.

For example,

SET JAVA_OPTIONS_WIN32=-server -Xms256m -Xmx256m ​-Dpsft_failtimeout=60 
-XX:MaxPermSize=128m -Xcomp

To determine the proper value for this property, you need to check the time in seconds that it takes to send an http(s) request from the browser to the web server and multiply the result by 2.

Enabling or Disabling HTTP Keep Alive

This section describes how to change HTTP Keep-Alive settings for a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to your managed server instance of PIA, PIA1, PIA 2, and so on.

Keep-Alive, or more accurately termed "Persistent Connections" is a default feature of HTTP. Keep-Alive allows for the client (generally a web browser) and the web server to maintain open connections between requests for specified period of time. That time period is generally less then 60 seconds. The benefit of a persistent connection is that the client and the server do not need to perform the overhead of opening a new connection with every single request.

Enabling Keep-Alive is generally recommended, but in some situations it may introduce problems. Sporadic "The Page cannot be displayed" errors, for example, can be the result of a problem with Keep-Alive. In situations where Keep-Alive issues are suspected, disabling the web server Keep-Alive and performing tests will help to determine if the problem is indeed related to connection persistence.

To enable or disable Keep-Alive:

1. Start the PIA server.

   See Starting WebLogic.

   See Stopping WebLogic.

2. Log on to the Administrative Console.

3. Navigate to the server's HTTP settings page.

   1. In the Domain Structure tree, click Environments.

   2. Click the PIA server (or your custom named PeopleSoft server) from the window on the right.

   3. Click the Protocols tab.

   4. Click the HTTP tab.

4. Change the Keep-Alive settings.

   • To disable Keep-Alive: Deselect Enable Keepalives and click Save. With Keep-Alive disabled, Duration and HTTPS Duration are not used.

   • To enable Keep-Alive: Select Enable Keepalives and update Duration and HTTPS Duration values as needed for your system.

   Click Save and Activate Changes.

5. Restart WebLogic Server.

Changing WebLogic User Passwords

The WebLogic domain built by the PIA install includes the following WebLogic IDs:

• system

• operator

• monitor

Each of those IDs have a default password of password. It is highly recommended to change the passwords for all of these user IDs on any production servers.

To change the passwords:

Note. The following instructions use the system user ID as an example, which has a default password of Passw0rd.

1. Start the PIA server.

   See Starting WebLogic.

   See Stopping WebLogic.

2. Log in to the Administrative Console.

3. Change a WebLogic Server user's password.

   1. In the Domain Structure tree, click Security Realms.

   2. In the Realms table, click myrealm.

   3. Select the Users and Groups tab.

   4. In the table of available users, click system.

   5. Select the Passwords tab.

   6. Enter and re-enter a new password for this user.

   7. Click Save.

4. With the system user ID, modify the boot.properties file with the new values:

   1. Open PIA_HOME\webserv\<domainname>\servers\PIA\security\boot.properties.

   2. Remove the previous, encrypted system value, and enter the new value in clear text.

      For example,

      #Tue Mar 31 12:09:14 PDT 2009
      password=newpassword
      username={3DES}S43Sj+0Gar0\=
      

   3. Save the file.

   4. Reboot the server, and test the login.

      Note. Rebooting the server should encrypt the clear text value you entered.

Note. When you run WebLogic as a Windows service, WebLogic uses the default ID of operator and password of password. Changing the password for the WebLogic ID that runs the Windows service requires an additional manual step of updating the setEnv.cmd, located in PIA_HOME\webserv\peoplesoft\bin. Set the WLS_PW environment variable to reflect the new password. Then, reinstall the Windows service by running the installNTservice command file located in PIA_HOME\webserv\peoplesoft\bin.

Implementing WebLogic SSL Keys and Certificates

This section provides an overview of Secure Sockets Layer (SSL) encryption with WebLogic and discusses how to:

• Obtain encryption keys.

• Prepare keys and certificates for the keystore.

• Import keys and certificates into the keystore.

• Configure WebLogic SSL encryption keys.

Understanding SSL Encryption with WebLogic

To use SSL encryption with WebLogic and the current PeopleTools release, the WebLogic keystore must contain the following appropriately configured encryption keys:

• The web server's private key.

• The web server's public key, digitally signed by a trusted certificate authority (CA).

• The digitally signed public key of the same CA that signed the web server's key.

A public key is transferred and stored as a data element in a digital certificate or a certificate signing request (CSR). You can obtain public keys from a variety of sources in several different formats.

When setting up SSL, you need to:

• ensure that the encryption keys are correctly formatted.

• install them in the keystore.

• configure them using the Administration Console.

Note. If you've already installed and configured a set of encryption keys for use with WebLogic in a previous PeopleTools release, you must migrate them as external files to the keystore within the current WebLogic version.

Obtaining Encryption Keys

If you already have a set of existing encryption keys configured as external files, you don't need to obtain new ones. To find the existing keys, refer to the documentation for the PeopleTools and WebLogic releases for which those keys were installed.

The following procedure describes how to obtain new encryption keys, using as an example the trial certificate available from Verisign.

To obtain new encryption keys:

1. At a command prompt, change to the following directory:

   PIA_HOME\webserv\domain_name

   Where domain_name is the name of the installed PeopleSoft Pure Internet Architecture domain for which you want to obtain encryption keys.

2. Enter the following command:

   pskeymanager -create

   Note. Pskeymanager is a script wrapper to Java's keytool, provided by PeopleSoft to manage the WebLogic keystore. For usage information, enter pskeymanager -help.

3. Follow the prompts and enter the requested information to create a new private key and a CSR for your web server.

   • Pskeymanager uses the keystore in PIA_HOME\webserv\domain_name\keystore\pskey, with a default password of password.

   • Pskeymanager prompts you for an alias for the new keys, for example, ServerABC. This is the name you'll use to refer to the keys in the future.

   • Pskeymanager prompts you for distinguished name fields. Enter the appropriate values for your organization.

   • Pskeymanager prompts you for information about the CSR expiration date, key size, key algorithms, and the private key password. All of these fields have default values.

   Pskeymanager creates the private key inside the keystore, and creates the CSR as a file called ServerABC_certreq.txt in the current directory. You use the CSR to obtain your signed public key certificate and a root certificate from a CA.

4. Decide which trusted CA you want to sign your web server's public key.

   You can use any CA that's compatible with Sun's Java JKS standard, such as Verisign.

5. Open your CSR file in a text editor and copy its entire contents, including the first and last lines:

   -----BEGIN NEW CERTIFICATE REQUEST-----
   ...
   ...
   -----END NEW CERTIFICATE REQUEST-----

6. Access Verisign's test certificate enrollment site at https://www.verisign.com/ssl/buy-ssl-certificates/free-ssl-certificate-trial/index.html.

   Verisign guides you through the CSR submission process, including:

   • Accepting the Verisign license agreement.

   • Entering your technical contact information, which includes the email address where Verisign can send your signed public key.

   • Pasting your CSR contents in the provided text field.

   • Verifying your CSR.

   • Confirming and submitting your order.

   Verisign also provides its own digitally signed public key in a certificate, which is known as a trusted CA certificate, a root certificate, or a chain certificate.

7. Download the VeriSign test CA root certificate from http://digitalid.verisign.com/cgi-bin/getcacert.

   When prompted, save getcacert.cer to PIA_HOME\webserv\domain_name.

   Note. If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode to PS_HOME/webserv/domain_name.

8. Check your email.

   Verisign digitally signs your web server's public key, then returns it to you in a certificate, called the server certificate. Following is an example of the contents of a server certificate:

   -----BEGIN CERTIFICATE-----
   DMICHDCCAcYCEAHSeRkM2guFL+6OvHr4AS0wDQYJKoZIhvcNAQEEBQAwgakxFjAP
   AANVBAoTDVZlcmlTaWduLCBLbAMxRzBFBgNVBAsTPnd3dy52ZXJpc2lnbi5jb20S
   VcVwb3NpdG9yeS9UZXN0Q1ETIEluY29ycC4gQnkgUmVmLiBMaWFiLiBMVEQuMUYF
   LIGEc3VyYW5jZXMgKEMpVRMxOSDFertdsfh67TIwNDAwMDAwMFoXDTAwMTIxODIA
   ONT1LVoweTELMAkGA1UERhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNK
   VBAUCOBsZWFzYW50b24BEzARBgNVBAoUClBlb3BsZVNvZnQxFDASBgNVBAsUC1BT
   Eb3sZVVvb2xzMRUwEwADVQQDFAxEQlJPV04xMTE0MDAwXDANBgkqhkiG9w0BAQET
   SAALADBEAkEAucfM/GOQhdkk4Q0ZD5i1l4gp6WTYMc4IaReoCYkEAmDKAVcYzY3R
   Mdbp4RC8SABd3bjjDOHcoCak9U6oSwL+HQIDAQABMA0GCSqGSIb3DQEBBAUAA0EO
   Arm3uf634Md0fqgNxhAL+e9rbY0ia/X48Axloi17+kLtVI1YPOp+Jy6Slp5iNIFC
   DhskdDFH45AjSDAFhjruGHJK56SDFGqwq23SFRfgtjkjyu673424yGWE5Gw4576K
   DosdDFG256EDHY45yTRH67i345314GQE356mjsdhhjuwbtrh43Gq3QEVe45341tS
   YDY6d47lDmQxDs9wGt1bkQ==
   -----END CERTIFICATE-----

9. Copy the entire certificate contents, and save it as a text file called ServerABC-cert.pem in PIA_HOME\webserv\domain_name.

   Be sure to include the first and last lines.

   Note. If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode.

Note. Make backup copies of the server certificate and the root certificate before proceeding.

Preparing Keys and Certificates for the Keystore

Your encryption keys must be in privacy enhanced mail (PEM) format, which is Base64-encoded data. Base64 encoding uses only ASCII characters. A PEM-formatted key or certificate file has an extension of either .pem or .cer. If the file is in the binary distinguished encoding rules (DER) format, it has a .der extension. Use the der2pem Java utility to convert DER-formatted keys and certificates to PEM format.

For SSL to work, your WebLogic server must present its own public key to each client browser, along with the self-signed public key of a root CA that's also in the browser's keystore, as well as any keys necessary to establish a chain of trust between the two. All of these keys must be part of the same certificate file before you can import them into the WebLogic keystore.

If you generated the private key using pskeymanager on a WebLogic platform, it's automatically correctly formatted, password protected, and installed in the keystore with no additional steps required. However, if the private key was configured as an external file on an earlier WebLogic platform/version, you must properly format it and incorporate a password, before importing it into the current WebLogic keystore along with the public key certificates.

Converting DER Files to PEM Format

It's important to convert all DER-formatted key and certificate files to PEM format before you work with them further.

To convert DER-formatted key and certificate files to PEM format:

1. At a command prompt, change to the following directory:

   PIA_HOME\webserv\domain_name

   Where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.

2. Enter the following command:

   setenv.cmd

   This sets the appropriate environment for Java commands.

3. For each DER-formatted key or certificate file, enter the following command:

   java utils.der2pem ​filename.der

   Make sure that you include the DER file's directory path. A new PEM file by the same name is created in the same location.

If you converted a private key file to PEM format, you must modify the header and footer to be compatible with WebLogic.

To modify the private key file header and footer:

1. Open the PEM-formatted private key file in a text editor.

2. Change the following line:

   -----BEGIN CERTIFICATE-----

   To this:

   -----BEGIN RSA PRIVATE KEY-----

3. Change the following line:

   -----END CERTIFICATE-----

   To this:

   -----END RSA PRIVATE KEY-----

4. Save and close the private key file.

Establishing the Server Certificate Chain of Trust

Your server certificate must contain, in addition to the web server's public key, any keys necessary to establish a chain of trust that culminates in the self-signed root certificate of a trusted root CA. That CA's root certificate must be in the keystore of any browser that's used to access your web server. Most browsers have an extensive set of trusted root certificates in their keystores.

First append the root certificate of the CA who issued your server certificate to the server certificate file. If you determine that the root certificate is not likely to be in your users' browsers, you must also append to the certificate file a chain certificate that was issued to your CA by another CA, then a chain certificate issued to that CA, and so on, until you append a root certificate that was issued by a trusted CA to itself.

For example, if your server certificate file is demo_cert.pem and the CA's root certificate is ca_cert.pem, you can open demo_cert.pem in a text editor, then insert the contents of ca_cert.pem after adding a new line at the end of the file. Make sure that each certificate follows the previous one on the next line, as follows:

...
...
DosdDFG256EDHY45yTRH67i345314GQE356mjsdhhjuwbtrh43Gq3QEVe45341tS
YDY6d47lDmQxDs9wGt1bkQ==
​-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
DMICHDCCAcYCEAHSeRkM2guFL+6OvHr4AS0wDQYJKoZIhvcNAQEEBQAwgakxFjAP
...
...

The result is that demo_cert.pem, for example, now contains the data from both certificates.

Note. You can also use the type command in Windows or the cat command in UNIX to combine the certificate files.

Password Protecting the Private Key

Private keys inside the WebLogic keystore are password protected. You can't import an external private key file into the keystore without a password. If it isn't currently password protected, use the WebLogic wlkeytool utility to incorporate a password into the private key file.

To password-protect an external PEM-formatted private key file:

1. At a command prompt, change to the following directory:

   WL–HOME\server\native\win\32

   Where WL_HOME is the root directory where you installed WebLogic.

2. Enter the following command:

   wlkeytool ​insecure_privatekey.pem ​secure_privatekey.pem

   Where insecure_privatekey.pem is the name of the original private key file, and secure_privatekey.pem is the name of the resulting password-protected private key file.

   Note. Make sure that you include directory paths for the private key files.

   The following message appears:

   Enter password to unprotect private key:

3. Press Enter.

   The following message appears:

   Private key not PKCS8 encoded, trying RSA key
   Private key file opened successfully
   Enter password to protect private key :

4. Enter the password that you want to use for this key.

   The following message appears:

   Verify password to protect private key :

5. Enter the password again to confirm it.

   The utility creates the password protected private key file that you specified. You import this key into the WebLogic keystore.

Importing Keys and Certificates Into the Keystore

Each WebLogic domain maintains its own keystore in PIA_HOME\webserv\domain_name\keystore\pskey, and all servers within a domain can share the same keystore.

These utilities are available for importing keys and certificates into the keystore:

Using pskeymanager to Import the Server Certificate

To import the server certificate into the WebLogic keystore:

1. At a command prompt, change to the following directory:

   PIA_HOME\webserv\domain_name\bin

   Where domain_name is the name of the installed PeopleSoft Pure Internet Architecture domain.

2. Enter the following command:

   pskeymanager -import

   Note. PeopleTools provides pskeymanager (a script wrapper to Java's keytool) to help manage the WebLogic keystore. For usage information, enter pskeymanager -help.

3. Follow the prompts and enter the requested information to create a new private key and a CSR for your web server.

   Keep the following in mind:

   • pskeymanager uses the keystore in PIA_HOME\webserv\domain_name\keystore\pskey, with a default password of password.

   • pskeymanager prompts you for an alias for the server certificate, for example, ServerABC. This should be the same alias that you specified for the corresponding private key when you created it.

   • pskeymanager prompts you for the name of the server certificate file, for example, ServerABC-cert.pem. Include the file path if necessary.

Using ImportPrivateKey to Import an External Private Key File with the Server Certificate

To import a password-protected private key and the server certificate into the WebLogic keystore:

1. At a command prompt, change to the following directory:

   PIA_HOME\webserv\domain_name\bin

   Where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.

2. Enter the following command:

   setEnv.cmd

   This sets the appropriate environment for Java commands.

3. Enter the following command:

   java utils.ImportPrivateKey keystore\pskey ​store_pass ​privatekey_alias 
   ​privatekey_pass ​servercert_file ​privatekey_file

   The parameters for this command are as follows:

   store_pass	Specify the password for the WebLogic pskey keystore. The default password is password.
   privatekey_alias	Specify an alias for the private key. This is the name by which the key will be accessible inside the keystore.
   privatekey_pass	Specify the password for the private key.
   servercert_file	Specify the path and name of the server certificate file that includes the issuing CA's root certificate.
   privatekey_file	Specify the path and name of the private key file.

Configuring WebLogic SSL Encryption Keys

This section describes how to configure the SSL encryption keys that you previously imported into the WebLogic keystore in PIA_HOME\webserv\domain_name\keystore\pskey, where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.

The following procedure applies to a single server configuration of PIA. In a production environment, you would perform these steps for managed server instances of PIA, PIA1, PSOL, RPS, and so on, in a multi-server domain configuration.

To configure WebLogic SSL encryption keys for the PIA server:

1. With the PIA server running, sign in to the Administration Console.

2. Access the keystore configuration pages.

   1. In the Domain Structure tree, expand Environment, click Servers, and click PIA from the Servers list.

   2. Select the Keystores tab.

   3. To change the configuration section, click Lock & Edit.

   4. Select Custom Identity and Custom Trust from the Keystores list.

3. Update the fields on the Configure Keystore Properties page as follows:

   Field	Value
   Custom Identity Key Store File Name	keystore/pskey This should be the relative path and name of the keystore into which you imported your SSL keys.
   Custom Identity Key Store Type	JKS Don't change this value.
   Custom Identity Key Store Passphrase	password
   Confirm Custom Identity Key Store Passphrase	Same as the value of Custom Identity Key Store Pass Phrase.
   Custom Trust Key Store File Name	keystore/pskey This should be the relative path and name of the keystore into which you imported your SSL keys.
   Custom Trust Key Store Type	JKS Don't change this value.
   Custom Trust Key Store Passphrase	password
   Confirm Custom Trust Key Store Passphrase	Same as the value of Custom Trust Key Store Pass Phrase.

   Warning! The default keystore and private key password is password. This should never be used in a production environment. You can change a private key's password and a keystore's password using pskeymanager's change password options: -changeprivatekeypassword and -changekeystorepassword, respectively.

4. Click Save.

5. Access the SSL tab, and update the values on the SSL Private Key Settings as follows:

   Field	Value
   Private Key Alias	Specify a unique identifier, such as the web server's machine name. This should be the alias that you specified for this server's private key.
   Passphrase	password
   Confirm Passphrase	Same as the value of Passphrase.

6. Click Save and Activate Changes.

   You must click the Activate Changes button to apply your changes. If you close your browser without clicking Activate Changes, your changes will be lost.

7. Restart the WebLogic PIA server.

Enabling TLS-Only on WebLogic

This section discusses:

• Configuring TLS-only on WebLogic Server.

• Configuring browsers for TLS.

• Configuring reverse proxy servers for TLS.

Configuring TLS-Only on WebLogic Server

The weblogic.security.SSL.protocolVersion command-line argument lets you specify which protocol is used for SSL connections.

To enable TLS-only on WebLogic Server:

1. Open PIA_HOME/webserv/<Domain>/bin/setEnv.cmd (Windows) or setEnv.sh (UNIX) in edit mode.

2. Append the following option to the JAVA_OPTIONS variable:

   -Dweblogic.security.SSL.protocolVersion=TLS1

   For example, on Windows in the setEnv.cmd, the updated JAVA_OPTIONS_WIN would appear as:

   SET JAVA_OPTIONS_WIN=-jrockit -XnoOpt -XXnoJITInline -Xms512m -Xmx512m
   -Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform
   -Dweblogic.security.SSL.protocolVersion=TLS1

3. Save the change.

4. Restart PeopleSoft Internet Architecture.

For more information about Supporting TLS1 protocol, refer to Oracle WebLogic documentation for specifying the version of SSL to be used.

See http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/ssl.html#wp1194608

Configuring Browsers for TLS

This section covers steps for configuring TLS on browsers.

Setting Up TLS on Microsoft Internet Explorer

To set up TLS on Internet Explorer:

1. Launch Internet Explorer.

2. Select Tools, Internet Options, and select the Advanced tab.

3. In the Settings box in the Security section, disable Use SSL 3.0 and enable Use TLS 1.0.

4. Click OK and restart the browser.

Setting Up TLS on Mozilla Firefox

To set up TLS on Firefox:

1. Launch Firefox.

2. Select Tools, Options, click the Advanced icon, and select the Encryption tab.

3. In the Protocols group box, disable Use SSL 3.0 and enable Use TLS 1.0.

4. Click OK and restart the browser.

Configuring Reverse Proxy Servers for TLS

It is strongly recommended to that you access the vendor's documentation of the web server you are using for a reverse proxy server and use their instructions for setting up TLS.

See Also

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslprotocol

http://docs.sun.com/app/docs/doc/819-2629/gczxu

http://support.microsoft.com/kb/187498

http://www.iis.net/

Working With WebLogic Session Cookies

When a user signs in to a PeopleSoft application, the portal servlet generates a cookie containing the user’s HTTP session ID, and sends it to the user’s browser to maintain the state of the session. The name of the cookie is fixed for all users accessing that portal.

On a WebLogic portal, the session cookie’s name is generated at install time based on the portal hostname and port number, which uniquely identify the portal within your PeopleSoft system. This name is stored in the portal’s weblogic.xml file.

However, the cookie name must not start with a number, and it must not contain any periods. If your users are experiencing problems signing in to PeopleSoft applications at different URLs from the same browser session, make sure that the session cookie names at those sites are valid.

To ensure valid WebLogic session cookie names:

1. Shut down your WebLogic server.

2. Open the weblogic.xml file for your web server in a text editor.

   You can find it in PIA_HOME\webserv\domain_name\applications\peoplesoft\PORTAL\WEB-INF.

3. Check the value of the session parameter called CookieName.

   Ensure that the content of the param-value element doesn’t start with a number or contain any periods. For example, the following session cookie name is invalid:

   <session-param>
     <param-name>CookieName</param-name>
     <param-value>57.28.208.21-80-WebLogicSession</param-value>
   </session-param>

   You can replace the periods with dashes (-). Following is a valid version of the session cookie name:

   <session-param>
     <param-name>CookieName</param-name>
     <param-value>c57-28-208-21-80-WebLogicSession</param-value>
   </session-param>

4. Save and close the file.

5. Restart your WebLogic server.

Securing Servlets on WebLogic

This section describes how to restrict access to a web resource for a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to your managed server instances of PIA, PIA1, PIA2, and so on. WebLogic Server provides an optional level of security to restrict access to resources on the web server.

The following steps describe how to restrict access to the PeopleSoft Portal servlet using a WebLogic ID and password. This, for example, could be applied to the report repository servlet.

To restrict access to a servlet:

1. Start the PIA server.

2. Open the Administration Console.

3. Change the security model to "Custom Roles And Policies":

   1. In the Domain Structure section select Security Realms, myrealm.

   2. Click Lock and Edit.

   3. For the Security Model Default field, select Custom Roles And Policies option from the drop down list.

   4. Click Save.

   5. Click Activate Changes.

   6. Select the default security model for the application to Custom Roles and Policies.

4. Enable security policy checks for web applications.

   1. Edit config.xml under PIA_HOME\webserv\<domain>\config.

      Note. Backup the file before you make any changes.

   2. Find the <app-deployment> section and add the following line in all of the <app-deployment> (or application deployment) sections:

      <security-dd-model>CustomRolesAndPolicies</security-dd-model>

      For example, one of the sections will look similar to the following:

      <app-deployment>
          <name>peoplesoft</name>
          <target>PIA</target>
          <module-type>ear</module-type>
          <source-path>applications/peoplesoft</source-path>
          <deployment-order>1</deployment-order>
          <security-dd-model>CustomRolesAndPolicies</security-dd-model>
          <staging-mode>nostage</staging-mode>
      </app-deployment>
      

   3. Save the file and restart the server so that the changes will take effect.

5. (Optional) Define the WebLogic users that you want to use.

   If you want to use one of the provided WebLogic user accounts (system, operator, or monitor) you can skip this step. Otherwise, create a new WebLogic user account:

   1. Under Domain Structure, select Security Realms, myrealm.

   2. Click Users and Groups tab.

   3. Under the Users tab, click New to create a new user.

   4. Enter user name and password and click OK.

6. (Optional) Create a user group, and add user(s).

   If you want to create a user group, add your users to that group and in the following steps select Caller is Member of group instead of User name of caller. To create a group:

   1. Under Domain Structure, select Security Realms, myrealm.

   2. Click the Users and Groups tab.

   3. Under the Groups tab, click New to create a new group.

   4. Enter the name of the group and description. Click OK.

   5. Select the Users tab, select your new user, and then click the Groups tab.

   6. Move the appropriate group from the Available box to the Chosen box.

7. Define a security policy for the PeopleSoft Portal web application.

   To restrict access to the Portal web application, perform the following in the navigation window on the left:

   1. Under Domain Structure, select Deployments, and select peoplesoft from the list of applications.

   2. Under Overview tab, select the portal module which appears as “/” in the Modules and Components table.

   3. Click the Security tab.

   4. Define a new URL pattern for this web module. Select New and enter the URL pattern as “/*” or specify the URL requiring authentication, and click OK.

   5. Select the URL pattern that you just created from the table and enter a security policy for this URL pattern.

   6. Add the condition to give access to the particular user you want to have access to this URL or any other conditions by clicking Add Conditions.

   7. To restrict access to a specific user, select the policy condition of User name of caller, click Add, and when prompted specify the user name. Repeat this step for additional users, groups, or access times. For access times, the server's local time is used.

   8. Click Finish and go back to the policy page and click Save.

      This action does not require a server reboot.

8. Test the configuration.

   Test your new security policy by accessing the URL you defined. If the security policy is active, you'll be prompted to sign in using a user ID that you added.

Adjusting the JVM Heap Size

Java options, such as JVM heap size and VM mode, used by the WebLogic server are stored in your WebLogic domain's setEnv script, stored in:

PIA_HOME\webserv\peoplesoft\bin

These options are specified in the script using the JAVA_OPTIONS_OSplatform environment variable. If you need to adjust any of the Java options, including changing the JVM heap size, you must manually edit the script.

The Microsoft Windows setEnv.cmd script contains the following default setting:

JAVA_OPTIONS_WIN32=-jrockit -XnoOpt -XXnoJITInline -Xms512m -Xmx512m 
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform

The UNIX standard setEnv.sh script contains the following default settings for supported Linux and UNIX platforms:

JAVA_OPTIONS_AIX="-Xms128m -Xmx256m -Dtoplink.xml.platform=⇒
oracle.toplink.platform.xml.jaxp.JAXPPlatform 
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
 
JAVA_OPTIONS_HPUX="-server -Xms256m -Xmx256m -XX:MaxPermSize=256m 
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform 
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
 
JAVA_OPTIONS_LINUX="-jrockit -XnoOpt -XXnoJITInline -Xms512m -Xmx512m 
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform 
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
 
JAVA_OPTIONS_SOLARIS="-server -Xms256m -Xmx256m -XX:MaxPermSize=256m 
-Dtoplink.xml.platform=oracle.toplink.platform.xml.jaxp.JAXPPlatform 
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"

You modify the Xms parameter to adjust minimum heap size, and modify the Xmx parameter to adjust maximum heap size. For most operating systems, the minimum and maximum values of the heap size are equal, which is recommended for better performance.

In a multi-server domain, the platform-specific versions of the JAVA_OPTIONS environment variable that appear in the setEnv script apply only to managed servers. The administration server doesn't use any of these variables, but it assumes default JVM heap size values of "-Xms256m -Xmx256m".

To adjust the JVM heap size for the administration server, add the environment variable JAVA_OPTIONS_ADMINSERVER following the last entry for JAVA_OPTIONS_OSplatform, and set it to your required minimum and maximum values, for example:

JAVA_OPTIONS_ADMINSERVER="-Xms128m -Xmx256m"

Note. If you're running WebLogic as a Microsoft Windows service and you modify setEnv.cmd, you must reinstall the service.

See Also

Managing JVM Heap Size

Determining the Service Pack Level

A summary of installed products and their versions and service pack levels is maintained in the BEA_HOME\registry.xml file. However, to confirm version information, it's more accurate to check the WebLogic log. A failed service pack install may be indicated in the log, but not found at runtime.

This section discusses how to:

• Check the WebLogic log

• Query WebLogic

Checking Version Information in the WebLogic Log

The WebLogic log is located in:

PIA_HOME\webserv\peoplesoft\servers\<server name>\logs\weblogic_server_weblogic.log

For version information, look for an entry similar to:

####<Nov 24, 2009 10:15:40 AM PST> <Info> <WebLogicServer> 
<RTDC79601VMC> <> <Main Thread> <> <> <> <1259086540827> <BEA-000214> 
<WebLogic Server "PIA" version:
WebLogic Server 10.3.2.0  Tue Oct 20 12:16:15 PDT 2009 1267925  
Copyright (c) 1995, 2009, Oracle and/or its affiliates. 
All rights reserved.> 
####<Nov 24, 2009 10:15:41 AM PST> <Notice> <Log Management> 
<RTDC79601VMC> <> <[ACTIVE] ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'> <> <> <> <1259086541014> <BEA-170019> 
<The server log file D:\PT851-
103TR1\webserv\On1032Nov24a\servers\PIA\logs\PIA_weblogic.log is opened. 
All server side log events will be written to this file.> 
#

Checking Version Information at the Command Line

To query a running WebLogic for version information from the command line, submit the following arguments to setEnv.

Windows:

While the WebLogic sever is up and running, from the command line, run setEnv and the following command in sequence.

C:\PIA851\webserv\peoplesoft\bin>setenv.cmd 
C:\PIA851\webserv\peoplesoft\bin>java weblogic.Admin
-url t3://localhost:80 -username <username> -password <password> VERSION

WebLogic Server 10.3 Fri Jun 23 20:47:26 EDT 2009 783464

UNIX:

While the WebLogic sever is up and running, from the shell command window, source the setEnv.sh file and issue the following command in sequence. For example,

rtdc60007stdb:$ . ./setEnv.sh
rtdc60007stdb:$ java weblogic.Admin
-url t3://localhost:80 -username <username> -password <password> VERSION

Enabling HTTP Access Log

This section describes how to change HTTP logging for a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to your managed server instance of PIA or PIA1, PIA 2, and so on.

To enable or disable HTTP access log:

1. Make sure the PIA server is running.

   See Starting WebLogic.

   See Stopping WebLogic.

2. Log on to the Administrative Console.

3. Open Server's Logging configuration page.

   1. In the Domain Structure tree, expand Environment, and click Servers.

   2. Click PIA (or your custom server name) in the Servers list.

   3. Select the Logging tab, and select the HTTP tab.

4. Enable HTTP access logging.

   1. Click the Lock&Edit button.

   2. Select the HTTP access log file enabled check box to turn on the access.log.

   3. Modify the Log file name field if desired.

   4. Click Save and Activate Changes.

5. Restart the WebLogic Server.