Working with IBM WebSphere

This chapter contains an overview and discusses:

Click to jump to parent topicUnderstanding WebSphere Application Server Within Your PeopleSoft Implementation

This section discusses:

Click to jump to top of pageClick to jump to parent topicDeploying PeopleSoft Applications With WebSphere

The IBM WebSphere Application Server (WAS) is a J2EE application server that PeopleTools uses as a web server to deploy PeopleSoft applications, as an alternative to Oracle WebLogic Server. To install and use WebSphere, download the appropriate version from Oracle E-Delivery site, and install it using the detailed instructions in the PeopleTools installation documentation.

Note. WebSphere Base edition and Network Deployment edition (ND) are packaged and installed together. PeopleSoft applications use the Network Deployment edition for application deployment.

See Also

PeopleTools 8.51 Installation for your platform

Click to jump to top of pageClick to jump to parent topicUsing The Integrated Solutions Console

To view and configure WebSphere settings, you use the web-based administrative console called Integrated Solutions Console, which is based on the Integrated Solutions Console (ISC) framework, providing a consistent and integrated capability for administering IBM software. The ISC enables you to access settings related to key areas of server administration, including:

To access ISC:

  1. Enter the following URL:

    http://WAS_Hostname:9060/ibm/console

  2. On the ISC login page, enter the appropriate credentials in the User ID field and click Login.

    If you have enabled Global Security, add the appropriate user ID and password. If Global Security is not enabled, add any user name in the User ID field (or leave it blank).

If you have more than one WebSphere server profile installed on a machine, the ISC port number for each installation is different. You can locate the port number corresponding to each profile by viewing the AboutThisProfile.txt file in:

PIA_HOME\webserv\<profilename>\logs

A key benefit of the ISC is that it allows administrators to create a custom navigation list of tasks performed more frequently, using the View, My Tasks feature in the upper, left-hand corner.

Note. You can perform numerous administrative tasks using ISC. This guide discusses those that pertain most specifically to deploying PeopleSoft applications. It is assumed that you are familiar with the topics contained in the IBM WebSphere documentation.

Note. In this document, we refer to the ISC as the "administrative console."

See Also

IBM WebSphere documentation

Click to jump to top of pageClick to jump to parent topicWebSphere Application Server Profiles

Different WebSphere Application Server environments are defined using profiles. A profile defines the runtime environment (JVM) for web applications. A profile includes:

PeopleSoft Internet Architecture makes use of the application server environment type to deploy the PeopleSoft Applications. When you run the PeopleSoft Internet Architecture installation, one of the elements that the system creates are the necessary application server profiles. The number of application server profiles created varies depending on whether you elected to implement a single server or multi server installation.

Note. The location for Application Server profile location differs from the default location when PIA creates Application Server Profile.

Single Server Installation

If you specified the default application name of "peoplesoft" at install time, an application server profile with the same name gets created in PIA_HOME\webserv\<peoplesoft>. When the PIA install creates an application server profile, it creates a default server names “server1” (single JVM process) and all of the PeopleSoft web modules are deployed to this single server.

You can view the PeopleSoft modules, such as PORTAL, PSEMHUB, PSIGW, and so on, in the single server profile directory structure.

PIA_HOME\webserv\<peoplesoft>\installedApps

Multi Server Installation

If you specified the default application name of "peoplesoft" at install time, the application server profile is created under PIA_HOME\webserv. In the case of a multi server installation, the profile contains the following separate servers.

Profile

Description

server1_peoplesoft

Hosts the PORTAL, PSIGW, and other web modules used for PeopleSoft online transactions.

PSEMHUB_peoplesoft

Hosts the PSEMHUB web module used by the PeopleSoft Environment Management Hub.

PSOL_peoplesoft

Hosts the PSOL web module used by the PeopleSoft Online Library Manager, which facilitates the HTML PeopleBooks installation.

Click to jump to top of pageClick to jump to parent topicIBM HTTP Server

The IBM HTTP Server is the IBM version of the Apache HTTP Server. It is a separate installation required for IHS and IHS plug-ins. You may use the IBM HTTP Server as a reverse proxy server within your PeopleSoft implementation.

See Also

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.ihs.doc/info/welcome_ihs.html

PeopleTools 8.51 Installation, “Installing Web Server Products”

Click to jump to parent topicStarting and Stopping WebSphere Application Servers

By default, all of the servers of a WebSphere instance are stopped when you install PIA. You need to start the server in order to access the PeopleSoft components.

To start and step WebSphere servers, use the delivered .BAT and .SH fiels located in:

PIA_HOME\webserv\<profilename>\bin

Note. During the server startup, the Dynamic runtime provisioning option is enabled by default. This option is used to selectively enable only the necessary containers (servlet container, EJB container, and so on) when a server starts.

Click to jump to top of pageClick to jump to parent topicStarting the WebSphere Server

To start the WebSphere server, enter the following command:

Operating System

Command

Windows

startServer.bat server_name -profileName profilename

UNIX

startServer.sh server_name -profileName profilename

Click to jump to top of pageClick to jump to parent topicStopping the WebSphere Server

To start the WebSphere server, enter the following command:

Operating System

Command

Windows

stopServer.bat server_name -profileName profilename

UNIX

stopServer.sh server_name -profileName profilename

Click to jump to parent topicConfiguring Reverse Proxy Servers For WebSphere

This section contains and overview and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Reverse Proxy Servers With IBM WebSphere

Using reverse proxy servers adds an additional, protective layer between your application and the internet or your end users. A reverse proxy server receives user requests, and sends them to a back end content server, usually behind a firewall. The back end server, in this case your PeopleSoft web server, remains unknown to the user.

For your PeopleSoft implementation, you can configure reverse proxy servers for WebSphere on the following web servers:

The communication between your web server and your reverse proxy server is configured using delivered plug-ins. You must install the web server software before you can install a plug-in for the web server. You can install the web server plug-in by itself on a machine where WebSphere Application Server ND has been installed but the plug-in has not. You can also install a plug-in on a remote machine where the HTTP proxy server is already installed.

Web Server Plug-In

Web server plug-ins enable the web server to communicate requests for dynamic content, such as servlets, to the application server. A web server plug-in is associated with each web server definition. The configuration file (plugin-cfg.xml) that is generated for each plug-in is based on the applications that are routed through the associated web server.

WebSphere RPS Plug-in

The RPS plug-in is used to forward HTTP requests from the proxy server to the PeopleSoft web server. The RPS plug-in provides:

Click to jump to top of pageClick to jump to parent topicConfiguring IBM HTTP Server as a Reverse Proxy Server

To configure the IBM HTTP Server for use as a reverse proxy server, you use the IHS plug-in.

Before you perform the following steps, you need to install the following items:

See PeopleTools 8.51 Installation, Installing Web Server Products, "Installing IBM HTTP Server 7.0 and Web Server Plug-ins"

To configure IHS for reverse proxy:

  1. Start WebSphere server and open the Administrative Console window.

  2. Navigate to Environment, Virtual Hosts, pia_host, Host Aliases.

    The PeopleSoft application is deployed on a virtual host called "pia_host".

  3. Create new entries for the required ports.

    For example:

    Hostname = *, Port =10001 (for web server port )

    Hostname = *, Port =10002 (for HTTP Administration Server port)

    Hostname = *, Port =10043 (for SSL port assigned to IHS)

  4. In a multi server environment, repeat the steps 2. and 3. for the other virtual hosts "psol_host" and "psemhub_host".

  5. Click Apply and save the settings to "master".

    This updates <PS_HOME>/webserv/profile_name/config/cells/node_name/virtualhosts.xml

  6. From the WebSphere Plug-ins installation, copy the configureWebserverDefinition script from the <Plugin_Install_Root>/bin to the directory <PS_HOME>/webserv/profile_name/bin and run it.

    This creates the web server definition in WebSphere server.

  7. Generate the plugin-cfg.xml by selecting the web server definition in Servers, Web servers.

  8. Copy the plugin-cfg.xml from <PS_HOME>/profile_name/config/cells/cell_name/nodes/node_name/servers/WebserverDefinition to <Plugin_Install_Root>/config/WebserverDefinition so that IHS can communicate with WebSphere directly and access the PeopleSoft application.

  9. Restart the WebSphere server, IBM HTTP Server, and IBM HTTP Administration Server.

  10. Verify accessing the PeopleSoft application using the IHS HTTP port.

Click to jump to top of pageClick to jump to parent topicConfiguring Microsoft IIS as a Reverse Proxy Server

This section discusses how to configure Microsoft IIS as a reverse proxy server for WebSphere. Before you perform these steps, the following items need to be installed:

Microsoft IIS Installation should have the following components already installed in order for the RPS setup to be successful:

See http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/tins_webplugins.html

See PeopleTools 8.51 Installation, Installing Web Server Products, "Installing IBM HTTP Server 7.0 and Web Server Plug-ins"

See your Microsoft IIS documentation

Installing WebSphere Web Server Plugin for Microsoft IIS

Before installing the plugin, create a new IIS website according to the instructions given in the IBM WebSphere "Installing Web Server Plug-ins" documentation. Alternately, you can use the Default website if it is available. The Plugins install wizard prompts for the location where the WebSphere plugins for IIS need to be installed and also for the location where WebSphere is installed. The wizard also prompts for the name of the web server definition to be created.

Note. The WebSphere image provided by Oracle for your PeopleSoft implementation, comes with 32-bit and 64–bit web server plugins. The 32-bit plugin installer is in CD1 and 64-bit plugin installer is in CD2. Install the appropriate plugin based on your machine architecture and the mode (32-bit or 64-bit) in which your IIS is running.

Configuring the Plugin on Microsoft IIS

To configure the plugin:

  1. From the WebSphere plugin installation, copy the configureWebserverDefinition script from the <Plugin_Install_Root>/bin to the directory <PS_HOME>/webserv/profile_name/bin.

  2. Start the WebSphere server and run the configureWebserverDefinition script from the PIA profile location.

    This creates the web server definition in the WebSphere server.

  3. In the Administrative Console select Environment, Virtual hosts, and add new Host Alias entries for the IIS web server HTTP port into following virtual hosts:

  4. Select Servers, Web servers, and select the server definition and generate the plugin-cfg.xml.

  5. Copy the plugin-cfg.xml from <PS_HOME>/profile_name/config/cells/cell_name/nodes/node_name/servers/WebserverDefinition to <Plugin_Install_Root>/config/WebserverDefinition.

    This enables the IIS web server to communicate with WebSphere directly and access the PeopleSoft application.

  6. Restart the Microsoft IIS web server, and start the IIS website that you have created.

  7. Restart the WebSphere server and login to the Administrative Console.

  8. (Optional) Enable Administrative Console to manage the IIS web server.

    This will show the IIS web server as running. This step is needed only if you want to manage your IIS web server from the WebSphere Administrative Console.

    1. In the Administrative Console select Servers, Server Type, Web servers.

    2. Click the web server definition to create one for the IIS web server.

    3. Enter the port number for the IIS web server.

  9. Access the PeopleSoft application through the IIS web server HTTP port:

    http://<hostname>:<IIS_HTTPPort>/ps/signon.html

Note. If you have a Windows 64-bit machine, IIS runs in 64-bit mode by default and requires 64-bit WebSphere plugins to be installed. However, if you have installed 32-bit WebSphere plugins then you can set IIS to run in 32-bit mode by executing the following script at the command prompt:

CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1 Restart the IIS web server following the execution of this script.

Click to jump to top of pageClick to jump to parent topicConfiguring Sun Java System Web Server as a Reverse Proxy Server

The following steps discuss how to configure the Sun Java System Web Server as a Reverse Proxy Server. Before you perform these steps, the following items need to be installed:

Installing WebSphere Plugin for Sun Java System Web Server

The Plugins install wizard prompts for the location where WebSphere and Sun Java System Web Server are installed. The wizard also prompts for the name of the web server definition to be created, the location of the obj.conf file, and the location magnus.conf file. These two configuration files can be found under the Sun Java System Web Server installation in the following directory:

$SunJava_Home/https-<hostname>/config

Configuring the Plugin

To configure the plugin:

  1. From the WebSphere Plugins installation, copy the configureWebserverDefinition script from the <Plugin_Install_Root>/bin to the directory <PS_HOME>/webserv/profile_name/bin.

  2. Start the WebSphere server and run the configureWebserverDefinition script from PIA profile location.

    This creates the web server definition in WebSphere server.

  3. In the Administrative Console, select Environment, Virtual Host, and add the new Host Alias entries for Sun Java System Web Server HTTP port into following virtual hosts:

  4. Select Servers, Web servers and generate the plugin-cfg.xml by selecting the web server definition.

  5. Copy the plugin-cfg.xml from <PS_HOME>/profile_name/config/cells/cell_name/nodes/node_name/servers/WebserverDefinition to <Plugin_Install_Root>/config/WebserverDefinition,

    This enables the Sun Java System Web Server to communicate with WebSphere directly and access the PeopleSoft application.

  6. Note the following entries in the Obj.conf file.

    After the <Object name=default> tag

Service fn="as_handler"
AddLog fn="as_term"

  7. Note the following entries in the Magnus.conf file.

    UNIX:

    Init fn="load-modules" 
     funcs="as_init,as_handler,as_term" 
     shlib="/opt/IBM/WebSphere/Plugins/bin/libns61_http.so"

Init fn="as_init" 
     bootstrap.properties="/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-⇒
cfg.xml"

    Windows:

    Init fn="load-modules" 
     funcs="as_init,as_handler,as_term" 
     shlib="C:\IBM\WebSphere\Plugins\bin\ns41_http.dll"

Init fn="as_init" 
     bootstrap.properties="C:\IBM\WebSphere\Plugins\config\webserver1\plugin-⇒
cfg.xml"

  8. Restart the Sun Java System Web Server.

  9. Restart the WebSphere web server.

  10. Access the PeoplesSoft application through the Sun Java System Web Server HTTP port.

    http://<hostname>:<SunJava_HTTPPort>/ps/signon.html

  11. (Optional) Enable Administrative Console to manage the Sun Java System Web Server.

    This will show the Sun Java System Web Server as running. This step is needed only if you want to manage your Sun Java System Web Server from the WebSphere Administrative Console.

    1. In the Administrative Console select Servers, Server Type, Web servers.

    2. Click the web server definition to create one for Sun Java System Web Server.

    3. Enter the port number for the Sun Java System Web Server’s.

Click to jump to parent topicSetting Up SSL For WebSphere

This section provides an overview and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding WebSphere Key Stores

WebSphere manages keys in key store files. There are two types of files:

These store types are very similar, however the trust store contains only trusted signers. The Certificate Authority (CA) certificates and other signing certificates are kept in a trust store. Personal certificates with private keys are stored in a key store.

The pskeymanager utility is a wrapper to Java's keytool, used to manage the predefined WebSphere keystore located in the following directory:

PIA_HOME\webserv\profilename\bin\pskey

Click to jump to top of pageClick to jump to parent topicGenerating a Certificate Using pskeymanager

Use the following steps to generate a self-signed certificate for the web container.

To generate a certificate using pskeymanager:

  1. At a command prompt, change to the WebSphere domain directory, for example:

    PIA_HOME \webserv\profilename\bin

  2. Create a new private key and certificate request for your server.

    1. Run the following command:

      pskeymanager.cmd -create

    2. Follow the prompts and specify the required information for creating a certificate, such as alias, common name, organizational unit, location, and so on.

    3. Make sure a Certificate Signing Request (CSR) file named alias_certreq.txt was created.

      You submit this data to a CA for obtaining a public key that you can load into your key store.

  3. Decide which CA you wish to use.

    You may use an CA that is compatible with Sun's Java JKS standard.

    As an example, the following steps indicate how to submit the CSR that you generated to Verisign to obtain a trial certificate.

  4. Submit your CSR to a CA.

    For example, access Verisign's test cart enrollment site at:

    https://www.verisign.com/products/srv/trial/intro.html

    When prompted, copy and paste the contents of your CSR, provide all necessary contact information, and submit the request.

  5. Check your email for the certificate sent from the CA.

    The certificate from the CA should look similar to the following:

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

    Copy the entire certificate, including --BEGIN CERTIFICATE-- and --END CERTIFICATE--, and save it as a file named webservername-cert.pem.

    Note. To save the file, don't use a word processor that inserts formatting or control characters.

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

  6. Download the CA root certificate:

    For example, download the Verisign trial root CA certificate.

    1. Download the Verisign Trial Root CA certificate from:

      https://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html

    2. From the specified link, click Select All, and copy the contents of the certificate into the verisignRootCA.cer file and save it to your WebSphere domain directory.

    3. Download VeriSign's Trial Intermediate CA certificate from:

      https://www.verisign.com/support/verisign-intermediate-ca/trial-secure-server-intermediate/index.html

    4. Click Select All and copy the contents of the certificate into the verisignInterCA.cer file, and save it into your WebSphere domain directory. You can also append the contents of this Trail Intermediate CA certificate to the Root CA certificate file verisignRootCA.cer.

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

  7. Import the CA's certificates into your key store.

    To import the CA's public certificate into your key store, run: 

    pskeymanager.cmd -import -trustcacerts

    For example, when prompted for an alias, specify the appropriate name to store the CA as, for example VerisignTrialCA. This name is only an alias for this certificate.

    When prompted for the certificate file to import, specify the root certificate, such as verisignRootCA.cer file.

    If any other certificates (such as the Verisign Intermediate certificate) are saved into a different file, run the command to import that certificate also.

  8. Import your certificate into your keystore.

    To import your public certificate into your keystore, run the following command from the command prompt

    pskeymanager.cmd −import

    When prompted for an alias, specify the same alias you did when you created your private key and certificate request.

    When prompted for the certificate file to import, specify your certificate file, webservername-cert.pem.

Click to jump to top of pageClick to jump to parent topicConfiguring the WebSphere Container to Support SSL

To complete the SSL configuration, the web container must be modified to use the self-signed certificates you created.

To set up WebSphere Container SSL:

  1. Start the Administrative Console, and select Security, SSL certificate and key management, Manage endpoint security configurations.

  2. On the Local Topology tab, expand the Inbound tree, and click on the appropriate node, as in peoplesoftNode.

  3. In the Related Items list on the right, click Key stores and certificates.

  4. In the resource table, click NodeDefaultKeyStore in the Name column.

  5. In the Additional Properties list on the right, click Personal certificates.

  6. Click Import.

  7. On the General Properties page, select the Key store file radio button, and complete the following:

    1. In the Key file name field, enter the fully qualified path to the keystore file containing the certificate to import.

      For example,

      C:\PSHCM\webserv\peoplesoft\bin\\pskey

    2. From the Type dropdown list, select JKS.

    3. In the Key file password, enter the password you specified when creating pskey.

    4. Click Get Key File Aliases.

      The system searches the key store and should populate the Certificate alias to import list.

    5. If you want to use a new alias, enter a new value in the Imported certificate alias field, otherwise leave it empty.

  8. Click Apply and OK.

  9. Save the configuration in the Administrative Console.

    Note. To configure Outbound SSL, repeat the same steps within the Outbound tree.

Click to jump to parent topicEnabling TLS-Only on WebSphere

Transport Layer Security (TLS) protocol is an improvement on the SSL v3 protocol. This section discusses:

Click to jump to top of pageClick to jump to parent topicConfiguring WebSphere for TLS

To enable TLS-only on WebSphere:

  1. Login to the administration console (http://host:adminport/ibm/console).

  2. Under the Security menu, select SSL certificate and key management, SSL configurations, NodeDefaultSSLSettings, Quality of protection (QoP) settings.

  3. Change the Protocol value to TLS or TLSv1.

    This ensures that WebSphere server will accept only TLS connections. That is, when the web server acts as a server (inbound) or as client (outbound) the SSL connections will be established through the TLS protocol. When testing from a browser make sure to check the browser settings to initiate TLS handshakes only.

Click to jump to top of pageClick to jump to parent topicConfiguring 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.

Click to jump to top of pageClick to jump to parent topicTesting TLS

After setting TLS for WebSphere and browsers, the TLS communication can be verified by logging in to the PeopleSoft application through WebSphere’s default SSL port (HTTPS).

For example:

https://<host_name>/<https_port>

You can find the HTTPS port in the WebSphere Administrative Console, by selecting Servers, Application Server, server1, ports. Find the port corresponding to the entry WC_defaulthost_secure.

Click to jump to top of pageClick to jump to parent topicConfiguring 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/

Click to jump to parent topicSecuring The Administrative Console and Applications For WebSphere

This section provides an overview, and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding WebSphere Security

This section discusses:

Registries and Repositories

With the IBM WebSphere Application Server, a user registry, or repository, authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. WebSphere makes access control decisions based on the information stored in the user registry or repository.

WebSphere supports multiple types of registries and repositories, including:

Security Domains

WebSphere allows "fine-grained security configuration" enabling security to be configured at the cell, node, server, or cluster level. Also, with WebSphere, you can configure application security separately for administrative security within a cell environment. Administrative security can be enabled through Global Security, while application security can be enabled by creating a new Security Domain and customizing the security configurations specific to the domain.

You configure separate applications to use different security configurations by assigning the servers, cluster, or Service Integration Buses hosting the applications or servlets to appropriate security domains.

Note. For a user to configure multiple security domains, they must be assigned to the administrator role.

For example, administration can be configured to use a federated repository while the applications can be configured to use an LDAP registry. In previous versions of Websphere, administrative and user applications use global security attributes by default, where a user registry defined in global security authenticates users for every application in the cell. Using multiple security domains provides more flexibility and simpler configurations.

This section illustrates how you can configure application security separately by creating a new security domain and assign it to the server level scope. The Administrative Console is secured with global security settings. The primary admin user belongs to the Local Operating System registry realm. The Report Repository Servlet of the PeopleTools application is secured by providing access to a user from another realm.

Note. For simplicity, in this example, both realms are Local Operating System realms. Realms may also be implemented as a Federated Repository or LDAP Registry.

See Also

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/csec_localos.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_sec_multiple_domains.html

Click to jump to top of pageClick to jump to parent topicSecuring the Administrative Console

This section discusses how to secure the Administrative Console for the profile associated with your PeopleSoft application. It is assumed that you have already set up user names and passwords on the host machine.

For Windows, the user should be in the Administrators group. On UNIX, use the root user.

This user information (user ID and password) will be used during configuration and authentication.

Configuring Administrative Security

To configure Administrative Security:

  1. Open the Administrative Console of the profile hosting the PeopleSoft application.

  2. Select Security, Global Security.

  3. In the User account repository group box, set Available realm definitions to Local operating system, and click Configure.

  4. In the Primary administrative user name field, enter a valid user name.

    In this example "ansrivat11" will be the admin user ID. This value is the name of a user with administrative privileges that is defined in the registry. This user name is used to access the Administrative Console or used by wsadmin. On UNIX this should be “root” user.

  5. Select the Server User Identity that is stored in the repository radio button, and enter the same user name as mentioned above for Server user ID or administrative user on version WAS 6.x node field, and enter the user’s password that corresponds to server identity.

  6. In the Custom properties table, click New, and enter these values:

    Name: com.ibm.websphere.registry.UseRegistry

    Value: local

  7. Click Apply and Save.

  8. Select Security, Global Security and click the Administrative user roles link, ensure that the user ID you just specified as the Primary administrative user name appears assigned to the Primary administrative user name role.

  9. Return to Security, Global security and set these options:

    1. Select the Enable administrative security check box.

    2. Select the Enable application security checkbox only if you want the application security to have the same global security configuration as the admin user. In this example, we illustrate the application security enabled separately within a separate domain.

    3. Deselect the Java 2 security options. PeopleSoft does not adhere completely to Java 2 security.

    4. Click Apply.

Configuring SSL

If you are using the default SSL configuration, extract the signer certificate from the WebSphere default Trust Store. If you have set up a customized SSL configuration extract the signer certificate corresponding to that configuration.

To configure SSL:

  1. In the Administrative Console select Security, SSL certificates and key management.

  2. Under Related Items, click Key stores and certificates.

  3. Click NodeDefaultTrustStore.

  4. Click Signer certificates.

  5. Select Root signer and click Extract.

  6. Enter a unique path and filename for the signer, such as c:\temp\rootsigner.arm.

  7. Click OK.

  8. Add the exported signer certificate to trust.p12 in the <PS_HOME>/webserv/<profile name>/etc directory to enable SSL connectivity.

    1. Open the key management utility, iKeyman, for that product version.

    2. Start ikeyman.bat or ikeyman.sh from <PS_HOME>/webserv/<profile name>/bin.

    3. Select Key Database File, Open.

    4. Open <PS_HOME>/webserv/<profilename>/etc/trust.p12.

    5. Enter WebAS for the password. (Do not change this password.)

    6. Select Add and enter the path to the signer certificate you extracted.

  9. Log out from the Administrative Console and stop the web server.

Modifying soap.client.props File

In any text editor, open the soap.client.props file located in PIA_HOME\webserv\<profile name>\properties. Set securityEnabled to true, and specify the appropriate user ID and password for loginUserID and loginPassword. For example,

com.ibm.SOAP.securityEnabled=true

com.ibm.SOAP.loginUserid=<user ID>
com.ibm.SOAP.loginPassword=<password>

Use the user ID and password used to access the Administrative Console. If you want to encode the password in this file then run the PropFilePasswordEncoder script located in the folder PS_HOME/webserv/<profileName>/bin. For example, 

PropFilePasswordEncoder.sh PS_HOME/webserv/<profileName>/properties⇒
/soap.client.props com.ibm.SOAP.loginPassword

Testing Administrative Console Security

Successfully starting the WebSphere Application Server and successfully logging into the Administrative Console verifies that Admin Security is enabled.

To test Administrative Console security:

  1. Start the server.

  2. Launch the Administrative Console.

  3. When prompted to log in, submit the user ID and password you configured previously.

  4. To ensure no PeopleSoft elements have been changed, sign on to PIA as well.

Click to jump to top of pageClick to jump to parent topicConfiguring Application Security

This section describes how to configure Application Security for WebSphere. In the context of PeopleSoft, the PeopleSoft servlets (PORTAL, Report Repository, and so on) run in the PeopleSoft application. In this discussion, we secure the access to the Report Repository servlet in the PeopleSoft application as the example.

Modifying and Deploying the Delivered EAR file

In this procedure, you modify the delivered peoplesoft.ear file and deploy it using the PeopleSoft install program.

To modify and deploy peoplesoft,ear:

  1. Locate the PeopleSoft ear file and move it to a temporary directory.

    Copy the PeopleSoft application ear file (peoplesoft.ear) from PS_HOME\setup\PsMpPIAInstall\archives folder into a temporary directory and extract it. In this discussion, C:\temp is used.

  2. Modify the application.xml file and add the <security_role> element as shown below.

    1. Open C:\temp\META-INF\application.xml.

    2. Add the security section shown below:

      <application>
...
...
...
<module>
<web>
<web-uri> helloportletapp.war</web-uri>
<context-root /helloportletapp</context-root>
</web>
</module>
<security-role>
<description>Role for SchedulerTransfer Servlet</description>
<role-name>SchedulerTransferRole</role-name>
</security-role>
</application>

    3. Save and close the file.

  3. Modify the PORTAL web.xml file.

    1. Extract C:\temp\PORTAL.war to C:\temp\PORTAL directory.

    2. Open C:\temp\PORTAL\WEB-INF\web.xml.

    3. Add the <security-constraint> and <security-role> element after the <welcome-file-list> element, and before the </web-app> element. In this case, the SchedulerTransferRole is mapped to the resource Report Repository servlet.

      ...
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>SchedulerTransferWebResource</web-resource-name>
<description>SchedulerTransferWebResourceDescription</description>
<url-pattern>/SchedulerTransfer/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description></description>
<role-name>SchedulerTransferRole</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description></description>
<role-name>SchedulerTransferRole</role-name>
</security-role>
</web-app>

    4. Save and close the file.

  4. Recreate PORTAL.WAR.

    1. Repackage PORTAL.war by running the following command

      cd C:\temp\PORTAL
jar -cvf ..\PORTAL.war *

    2. Delete the C:\temp\PORTAL directory.

  5. Repackage the peoplesoft.ear file by running the following command in the temporary directory.

    jar -cvf ..\peoplesoft.ear *

  6. Copy the recreated ear file into PS_HOME\setup\PsMpPIAInstall\archives.

  7. Deploy the recreated ear file onto WebSphere using the PeopleSoft Internet Architecture installation program.

Create a New Security Domain For Application Security

Creating a separate security domain for applications enables you to assign tailored security attributes to the application.

To create a security domain:

  1. Select Security, Security domains, and click New.

  2. Provide a name and description for the security domain, and click OK.

  3. Define the scope.

    For this example, the scope is server1, but other implementations can set the scope at Cell, Clusters, Nodes, and so on.

  4. Under Security Attributes, expand Application Security and select the Customize for this domain radio button, and select the Enable application security check box.

  5. Expand User Realm, and select Customize for this domain, select a Realm type, and click Configure.

    In this example, Local operating system is used, but any of the realm types can be used. The realm selected will need to contain the users who are authorized to access the resource, which in this case is the Report Repository servlet.

    For this example, when configuring the realm, we use appRealm for the Provide a realm name field. In the Custom properties table we use com.ibm.websphere.registry.UserRegistry (Name) and local (Value).

Mapping Security Roles to User Groups

To map security roles to user groups:

  1. Select Applications, Application Types, WebSphere enterprise applications, and click peoplesoft.

  2. Click Security role to user/group mapping.

  3. Select SchedulerTransferRole and click on Map Users.

  4. Select the User realm as the one created for the application, in this case it is the "appRealm".

  5. Click the Search button to display all the available user IDs for this realm.

    For this example, we select the user ID ansrivat12 for the SchedulerTransferRole. This ensures that only the user ansrivat12 is authorized to access the Report Repository servlet.

Testing Application Security

Restart the web server. Test the security of Report Repository servlet (as we configured it in this example) by using the following URL:

http(s)://<hostname>:<PIA http(s) port>/SchedulerTransfer/ps

You should be prompted for user ID and Password dialog. If authentication is successful, you should be shown the servlet output.

Click to jump to parent topicSetting HTTP Session Timeout

HTTP session timeout controls are accessible on the Security page of the web profile interface. PeopleSoft Internet Architecture ignores any session timeout control set on the web server. At run time, the session timeouts set in the web profile override any HTTP session timeouts set at the web server level.

Click to jump to parent topicSetting 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 -Xms<nnn>m -Xmx<nnn>m ​-Dpsft_failtimeout=60 -XX:Max⇒
Perm⇒
Size=<nnn>m -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.

Click to jump to parent topicWorking With JVM Heap Size

Adjusting the JVM heap size settings can improve performance in some situations, however, the default settings are typically adequate for most situations.

To access the JVM heap size properties:

  1. In the Administrative Console, select Servers, Server Types, WebSphere application servers, and click on your server in the resource list.

  2. Select the Configuration tab, and in the Server Infrastructure section expand Java and Process Management, and click Process definition.

  3. In the Additional Properties, click Java Virtual Machine.

The JVM heap size properties are:

Property

Description

Initial heap size

The initial heap available to the JVM.

If blank, the system assumes the default value of 50 MB.

Maximum heap size

The maximum heap available to the JVM.

If blank, the system assumes the default value of 256 MB.

IBM recommends that if you determine that garbage collection occurs more than desired, increase the Maximum heap size value.

See Also

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0//index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/xrun_transport.html

Click to jump to parent topicWorking with Logging and Tracing Options

In addition to the logging and tracing options PeopleTools provides, WebSphere also offers a variety of tracing options.

See Also

Your IBM WebSphere Application Server and Administrative Console documentation

Click to jump to top of pageClick to jump to parent topicEnabling HTTP Access and HTTP Error Logging

To enable HTTP access and error logging:

  1. In the Administrative Console, select Servers, Server Types, WebSphere application servers, server1, and click the NCSA access and HTTP error logging link.

  2. Enable HTTP access logging by selecting the options Enable logging service at server start-up and Enable access logging.

    The HTTP access logs will be written to PS_HOME/webserv/profileName/logs/server1/http_access.log.

  3. Enable HTTP error logging by selecting Enable error logging.

    The HTTP error logs will be written to PS_HOME/webserv/profileName/logs/server1/http_error.log.

Click to jump to top of pageClick to jump to parent topicEnabling General Logging and Tracing

To access WebSphere logging and tracing options:

  1. In the Administrative Console, select Servers, Server Types, WebSphere application servers, and clicking on your server in the resource list.

  2. In the Troubleshooting section, click Logging and tracing.

The diagnostic trace, JVM log, and process log output files are directed to a variable, ${SERVER_LOG_ROOT}, which refers to the following location on a typical PeopleSoft installation:

PIA_HOME\webserv\profilename\logs\server

The IBM Service log output file is directed to a variable, ${LOG_ROOT}, which refers to the following location on a typical PeopleSoft installation:

PIA_HOME\webserv\profilename\logs\