Jazz Library Configuring Enterprise CLM Reverse Proxies, Part 2: WebSphere 8 and IHS 8
Author name

clm,elm

Fri, 10 May 2013
5 min read
0

Configuring Enterprise CLM Reverse Proxies: WebSphere 8 and IHS 8

Sudhakar Frederick: Jazz Jumpstart Team
Last updated: February 15, 2013
Build basis: Rational solution for Collaborative Lifecycle Management 4.0.1, Websphere Application Server (Base) 8.0.0.2, IBM HTTP Server 8.0.0.2

Please be aware:The content of this article has been migrated to the Deployment wiki: Configuring Enterprise CLM Reverse Proxies: WebSphere 8 and IHS 8 topic page. The content will be maintained and updated in the wiki going forward. Therefore, this version of the article might not contain the most up to date information.

All deployment guidance and best practice will be published in the Deployment wiki rather than as Jazz.net articles going forward.

This guide will explain how to setup and configure an example CLM environment using WebSphere Application Server (WAS), IBM HTTP Server (IHS) and the WAS web server plugins for IHS, such that users will be able to access the various CLM applications simply by changing the context root of a central URL which is processed by IHS. IHS will take care of sending the requests to the appropriate JTS/CCM/QM/RM application servers operating behind the proxy.

Note that Article 745 covers this same ground with Websphere 7.x and IHS 7.x. There have been some changes in the installation and configuration processes in Websphere 8 and IHS 8 which are covered here.

Other articles in this series:

Table of Contents

Configuring the WAS Web Server plugins with WAS 8 and IHS 8
Procedure
  1. Create a key database and self-signed certificate for IHS
  2. Enable SSL directives within the IBM HTTP Server’s configuration file (httpd.conf)
  3. Setup SSL Handshake Between the WAS profiles and IHS
  4. Force WAS To Honor Host Headers
  5. Single Sign-On(SSO) with WAS
  6. Configure WAS IHS Plug-in for JTS (Server 1)
  7. Configure WAS IHS Plug-in for RM application (Server 1)
  8. Configure WAS IHS Plug-in for the QM application (Server 2)
  9. Configure WAS IHS Plug-in for the CCM application (Server 3)
Running the JTS Setup wizard
Moving an application
Using the command line
References
About the author

Configuring the WAS Web Server plugins with WAS 8 and IHS 8

There are two methods used to deploy the WAS Web Server plugins depending on whether IHS and the WAS profiles are local or remote. To demonstrate both methods, we will assume that the JTS, RM application server profiles are co-located with the IHS server (local), with the QM and CCM applications each on their own servers (remote).

The user accessible Public URIs (and the actual servers they redirect to) will be:
https://clm.example.org/qm (https://qmserver01.example.org:9443/qm)
https://clm.example.org/jts   (https://clm.example.org:9447/jts)
https://clm.example.org/rm   (https://clm.example.org:9448/rm)
https://clm.example.org/ccm   (https://ccmserver01.example.org:9449/ccm)

We will also configure single sign-on with WAS such that a user only needs to log into one of the products and subsequent access to the other applications will not require re-authentication.
Experienced WAS administrators will be aware that the WAS configuration steps in this guide can be carried out in different ways using “wsadmin” or the WAS Integrated Solutions console.

N.B. Note that all of the setup and configuration documented here MUST be done *before* running the JTS setup wizard to ensure that the public URIs are set correctly to the external URIs.

Example server configuration

For the purposes of this article we use three separate servers configured as follows:
  • Server 1 (Host-name: clm.example.org):
    • IBM HTTP Server already installed, listening on port 80 with the IHS Administrative console on port 8008
    • WAS profile with JTS, Admin and CLMHelp applications deployed (HTTPS port : 9447)
    • WAS profile with RM WAR deployed (HTTPS port : 9448)
  • Server 2 (Host-name: qmserver01.example.org):
    • WAS profile hosting QM (HTTPS port: 9443)
  • Server 3 (Host-name:ccmserver01.example.org):
    • WAS profile hosting CCM (HTTPS port: 9449)

Prerequisites and Assumptions

  • Base Websphere Application Server profiles are used (ie. not Websphere ND, which is covered by this article)
  • Use the instructions provided in the CLM Infocenter to deploy the different applications
  • Each of the WAS profiles is configured to use LDAP domain “example.org” for authentication 
  • A separate database server is available
  • The WebSphere Plug-ins for WebSphere® Application Server Version 8.0 have been installed on server 1 to <plugin install dir>
  • Administrative console access to each WAS profile is available
  • Username and password available for access to IHS Administrative console
  • Firewalls on the two servers are configured appropriate, allowing access to the internal ports only between the three servers. In other words ports 9443, 9447, 9448, 9449, 8008 are not visible to the outside world
  • The firewall on Server 1 allows access to port 443 from the outside world
  • Though the steps here were carried out in a Linux enviroment, their Windows equivalents will work as well.

Procedure

1. Create a key database and self-signed certificate for IHS

In this step we create a CMS keystore database file and a self-signed certificate which are needed to authenticate IHS during an SSL handshake. Note that Self-signed certificates should only be used for test/development scenarios. In production environments use the appropriate organizational certificates provided by a trusted certificate authority. We will later add the WAS certificates to this same keystore database.

Make sure the IHS Server is stopped.
Run the “gsk7cmd” utility (alternatively use the ikeyman GUI) to create a new keystore database (ihskeys.kdb) and password stash file (ihskeys.sth) both of which will be created in the current directory.

  gskcmd -keydb -create -db ihskeys.kdb -pw secret -expire 365 -stash -type cms

Create a self-signed certificate and add it to the the new keystore db

  gskcmd -cert -create -db ihskeys.kdb  -label clm.example.org -expire 365 -dn "CN=clm.example.org" -default_cert yes -pw secret

2. Enable SSL directives within the IBM HTTP Server’s configuration file (httpd.conf)

In this step we need to first direct IHS to load the SSL support module (mod_ibm_ssl.so) and then direct IHS to listen for secure requests (on port 443 in this example). We also need to point IHS to the key database file (ihskeys.kdb) and password stash file (ihskeys.sth) that were created earlier.
Add (or uncomment) the following lines in httpd.conf, making sure that the values for the KeyFile and SSLStashFile directives match the names (and paths) of the files generated in the previous section:

  LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

Listen 0.0.0.0:443
## Uncomment for IPv6 support:
#Listen [::]:443
<VirtualHost *:443>
SSLEnable
</VirtualHost>
KeyFile /opt/IBM/HTTPServer/bin/ihskeys.kdb
SSLStashFile /opt/IBM/HTTPServer/bin/ihskeys.sth
SSLDisable

3. Setup SSL Handshake Between the WAS profiles and IHS

Now we need to proxy SSL requests from IHS to the WAS servers by exporting the WAS keys and importing them into the IHS keystore database previously created.
  1. Login to the WAS Integration Solutions Console for the JTS profile.
  2. Navigate to Security -> SSL certificate and key management -> Key Stores and Certificates, create a new Key store with the following values:
    Name: jtswaskeys
    Path: jtswaskeys.kdb
    Type: CMSKS
    Password:secret
    Create JTS WAS Keys
  3. Click OK then Save. This will create the file <jtswasprofileroot>/etc/jtswaskeys.kdb.
  4. Navigate to SSL certificate and key management -> Key stores and certificates -> NodeDefaultKeyStore
  5. Choose “Personal certificates” from the right sidebar
  6. Check the default certificate and click Export.
  7. Specify the following values in the Export certificates pane:
    Key Store Password: WebAS (unless this has been changed)
    Select the “Key Store File” radio button
    Key File Name: <jtswasprofileroot>/etc/jtswaskeys.kdb
    Type: CMSKS
    Password: secret
    exportjtswaskeys.png
  8. Click OK. This will export the default WAS personal certificates into <jtswasprofileroot>/etc/jtswaskeys.kdb.
  9. Add the certificates from the exported keystore (jtswaskeys.kdb) into the previously created IHS keystore(ihskeys.kdb).
  gskcmd -cert -import -db <jtswasprofileroot>/etc/jtswaskeys.kdb -pw secret -type cms -target ihskeys.kdb -target_pw secret -target_type cms -label default -new_label default_jtswas

Repeat the above steps, changing the value of Key File Name as appropriate for each of the CCM(ccmwaskeys.kdb), RM (rmwaskeys.kdb)and QM profiles (qmwaskeys.kdb). Note that since the CCM and QM WAS profiles are *not* co-located with the IHS server, we first need to copy “qmwaskeys.kdb” and “ccmwaskeys.kdb” to the IHS server.

4. Force WAS To Honor Host Headers

To avoid a problem with Jazz redirecting to :9443 ports on the IHS Server we need to set a couple of Web Container custom properties in WAS.

  1. Login to the WAS Integration Solutions Console for each WAS profile and navigate to Servers -> Server Types -> WebSphere application servers -> server1
  2. Under “Container Settings” expand Web Container Settings. Choose “Web Container“.
  3. Add the following custom properties:
  trusthostheaderport = true  com.ibm.ws.webcontainer.extracthostheaderport = true

webcontainercustom

5. Single Sign-On(SSO) with WAS

To allow sharing of authentication tokens between the different WAS profiles, we need to enable the SSO property in each WAS profile, export the LTPA (Lightweight Third Party Authentication) keys from one profile and import them into each of the other profiles.

5.1 Setup JTS profile for SSO and export keys

  1. Login to the WAS Integration Solutions Console for the JTS WAS profile.
  2. Navigate to Global Security -> Web and SIP Security -> Single sign-on (SSO) and set the following properties:
    Enabled
    Domain name: example.org
    Requires SSL
    websipssosetting.png
  3. Click OK then Save.
  4. Navigate to Global Security,select LTPA and enter the following values:
    Password     : secret
    Confirm Password     : secret
    Fully qualified key file name     :<jtswasprofileroot>/etc/jtsssokey
  5. Click Export keys.
    LTPAexport.png
  6. Click OK then Save. This will create a file <jtswasprofileroot>/etc/jtsssokey which we will import into the other WAS profiles.
  7. Stop and restart the JTS profile.

5.2 Setup RM, QM and CCM for SSO and import JTS keys

  1. Copy the jtssokey generated above from <jtswasprofileroot>/etc to <rmwasprofileroot>/etc/jtsssokey
  2. Login to the WAS Integration Solutions Console for the RM WAS profile.
  3. Navigate to Global Security -> Web and SIP Security -> Single sign-on (SSO) and set the following properties:
    Enabled
    Domain name     : example.org
    Requires SSL
    websipssosetting.png
  4. Click OK then Save.
  5. Navigate to Global Security,select LTPA and enter the following values:
    Password     : secret
    Confirm Password     : secret
    Fully qualified key file name     : <rmwasprofileroot>/etc/jtsssokey
  6. Click Import keys.
  7. Click OK then Save.
  8. Stop and restart the RM profile.

Repeat the above steps for each of the CCM and QM profiles, copying the jtsssokey file to the <ccmwasprofileroot> and <qmwasprofileroot> respectively.

6. Configure WAS IHS Plug-in for JTS (Server 1)

We will now use the WAS Web Server Plug-ins Configuration Tool to configure IHS such that all requests to https://clm.example.org/jts are redirected to https://clm.example.org:9447/jts.
As noted before, for the purposes of this example,the WAS profile to which the JTS application has been deployed is co-located on the same server as IHS. We therefore use the procedure described in Configuring a Web server and an application server profile on the same machine.

The following steps are performed on “Server 1′ which hosts both IHS and the WAS profile hosting the JTS, Admin and CLMHelp applications.

6.1Generate the plugin configuration file

  1. Stop the JTS WAS profile.
  2. Stop IHS.
  3. Launch the Plug-ins Configuration Tool.
    webserverplugininstall01.png
  4. Click Add….
  5. Enter “webserver1” for Name and “<plugin installdir>/Plugins” for Location. Click Finish.
  6. Click create and choose “IBM HTTP Server V8” for Web server type and click Next.
    webserverplugininstall03.png
  7. Click Browse to select the configuration file for IHS, verify that the Web server port is correct, and then click Next when you are finished.

  8. Optionally configure access to the IBM HTTP Administration Server. This not required but makes it easy to propagate the plugin configuration file from the application server to the web server.
  9. Specify a unique nickname for the Web server. Click Next.
  10. Select WebSphere Application Server machine (local), browse to the installation directory and click Next.
    webserverplugininstall04.png
  11. Select the profile that the JTS application is deployed to and click Next.
  12. Click Configure on the Plug-in Configuration Summary panel. The wizard begins configuring the Web server and the application server. Note the path of the Plug-in configuration file, which we will use later.
  13. Verify the success on the Plug-in Configuration Summary panel and click Finish to exit the wizard.

6.2 Modify keyring and stashfile properties

  1. Open the generated plugin configuration file (C:IBMHTTPServerPluginsconfigwebserver1plugin-cfg.xml in this case) and modify the keyring and stashfile properties of the HTTPS Transport attributes to use the IHS keyfile and SSL Stashfile. 
      <Transport Hostname="clm.example.org" Port="9447" Protocol="https">  <Property Name="keyring" Value="<path to ihskeys>/ihskeys.kdb"/>  <Property Name="stashfile" Value="<path to ihskeys>/ihskeys.sth"/>  </Transport>
  2. Start IHS and the JTS WAS profile.
First verify that you can access the JTS page using the “internal” URL: https://clm.example.org:9447/jts. Next verify that the IHS URL https://clm.example.org/jts displays the same page.

7. Configure WAS IHS Plug-in for RM application (Server 1)

As noted before, for the purposes of this example, the WAS profile to which the RM application has been deployed is co-located on the same server as IHS and the JTS profile.
This is similar to the procedure used for the JTS with the exception that we will need to merge some of the content from the plugin configuration file generated for the RM profile into the plugin configuration file already created for the JTS.

The following steps are performed on “Server 1′ which hosts both IHS and the WAS profiles hosting the RM and JTS applications.

7.1Generate plugin configuration file

  1. Stop the RM WAS profile.
  2. Stop IHS.
  3. Copy the previously generated <path to plugin installdir>/config/webserver1/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/jts-plugin-cfg.xml”.
  4. Launch the Plug-ins Configuration Tool on server1. Since the httpd file for the IHS server already contains the plugin entries for the JTS, the Plug-in configuration tool will balk at the Web Server Configuration File Selection pane (see Step 7 in Section 6.1). To get around this we first delete the previous configration (making sure we copied the config file in the previous step).
    webserverplugininstall01.png
  5. Once the reference has been deleted , click Create and follow the same process as before
    • choose the same httpd.conf file
    • do not configure the HTTP Administration server as it has already been done
    • specify “webserver1” for the web server definition
    • choose WebSphere Application Server machine (local), browse to the installation directory and select the “RM” profile
  6. When the wizard completes, modify the keyring and stashfile properties as in Section 6.4, and copy the newly generated <path to plugin installdir>/config/webserver1/plugin-cfg.xml to <path to plugin installdir>/config/webserver/rm-plugin-cfg.xml

7.2 Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the RM profile into the plugin configuration generated for the JTS using the pluginCfgMerge tool. 
  wasinstall_root/bin/pluginCfgMerge.sh rm-plugin-cfg.xml jts-plugin-xml plugin-cfg.xml

7.3 Edit httpd.conf

Open the IHS httpd.conf file in a text editor and change the WebSpherePluginConfig directive to point to the merged plugin configuration file. 
WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml"
Restart IHS.
First verify that you can still access the JTS page using the IHS URL https://clm.example.org/jts.
Next verify that you can access the RM page using the “internal” URL: https://clm.example.org:9448/rm. Next verify that the IHS URL https://clm.example.org/rm displays the same page.

8. Configure WAS IHS Plug-in for the QM application (Server 2)

We will now use the WAS Web Server Plug-ins Configuration Tool to configure IHS such that all requests to https://clm.example.org/qm are redirected to https://qmserver01.example.org:9443/qm and. As noted before, for the purposes of this example, the WAS profile to which the QM application has been deployed is *not* co-located on the same server as IHS. We therefore use the procedure in Configuring a Web server and an application server on separate machines (remote).

The following steps are performed on “Server 1′ which hosts IHS.

8.1 Generate manual plugin configuration script

  1. Stop IHS.
  2. Copy the previously generated <path to plugin installdir>/config/webserver/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml.
  3. Launch the Plug-ins Configuration Tool on server1. Again we first remove the reference to the previous file from the Configuration tool.
    webserverplugininstall01.png
  4. Once the reference has been deleted , click Create and follow the same process as before
    • choose the same httpd.conf file
    • do not configure the HTTP Administration server as it has already been done
    • specify “webserver1” for the web server definition
    • choose (Remote) application server and enter the host name of the QM Server
  5. Once the installation completes, the wizard generates a manual configuration script which must be run on the QM server. The path to the script is displayed in the installation summary panel.

The following steps are performed on “Server 2′ which hosts the WAS profile hosting the QM application.

8.2 Run manual configuration script on Server 2

We now copy the manual configuration script generated above to the <was_install_root> /bin directory on Server 2.
If the WAS profile hosting the QM application isn’t already running start it.
Run the  configurewebserver1.sh script.
If it runs successfully, a web server definition will have been created in the QM application server profile.

8.3 Propagate the QM plugin configuration file to the IHS server

  1. Login to the WAS Integration Solutions Console for the QM WAS profile.
  2. Navigate to Servers -> Server Types -> Web Servers
  3. Select “webserver_qm” and click “Generate Plug-in”.
  4. Once the plugin file has been generated, select “webserver1” and click “Propagate Plug-in”.


    If successful WAS will generate a message such as:
      InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server. 
    qm.clm.example.org-node.webserver1.
    Note the path displayed for the generated plugin configuration file on Server 1 which is the IHS Server.

The following steps are performed on “Server1′ which hosts IHS.

8.4 Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the QM profile into the plugin configuration that contains the merged directives for the JTS and RM profiles.
Remember that in step 8.1 we copied the <path to plugin installdir>/config/webserver/plugin-cfg.xml to <path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml. Run the pluginCfgMerge tool to merge the contents of the new plugin-cfg.xml propagated from the QM server. 
  wasinstall_root/bin/pluginCfgMerge.sh <path to plugin installdir>/config/webserver1/plugin-cfg.xml <path to plugin installdir>/config/webserver/rm-jts-plugin-cfg.xml  <path to plugin installdir>/config/webserver/plugin-cfg.xml

8.5 Edit httpd.conf

Open the IHS httpd.conf file in a text editor and change the WebSpherePluginConfig directive to point to the merged plugin configuration file. 
WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml"
Restart IHS.
First verify that you can still access the JTS and RM pages using the IHS URL https://clm.example.org/jts and https://clm.example.org:9448/rm.
Next verify that you can access the QM page using the “internal” URL: https://qmserver01.example.org:9443/qm. and then  verify that the IHS URL https://clm.example.org/qm displays the same page.
Copy the <path to plugin installdir>/config/webserver/plugin-cfg.xml to another file such as <path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml.

9. Configure WAS IHS Plug-in for the CCM application (Server 3)

We will now configure IHS such that all requests to https://clm.example.org/ccm are redirected to https://ccmserver01.example.org:9443/ccm. As noted before, for the purposes of this example, the WAS profile to which the QM application has been deployed is *not* co-located on the same server as IHS. We therefore use the procedure in Configuring a Web server and an application server on separate machines (remote). However we have already generated the manual configuration script for the QM profile in Section 7. Since the script is designed to accept the WAS profile name, administrative username and password as parameters we can simply reuse it.

9.1 Run manual configuration script generated for QM on Server 3

The following steps are performed on “Server3′ which hosts the CCM profile.

  1. Copy the previously generated cofigurewebserver1.sh from Server 1 to the <app_server_root>/bin directory.
  2. Run the script: 
      wasinstall_root/bin/cofigurewebserver1.sh CCM username password
    If it runs successfully, a web server definition will have been created in the CCM application server profile.

9.2 Propagate the CCM plugin configuration file to the IHS server

  1. Login to the WAS Integration Solutions Console for the CCM WAS profile.
  2. Navigate to Servers -> Server Types -> Web Servers
  3. Select “webserver1” and click “Generate Plug-in”.
  4. Once the plugin file has been generated, select “webserver1” and click “Propagate Plug-in”.

    If successful WAS will generate a message such as:
      InformationPLGC0048I: The propagation of the plug-in configuration file is complete for the Web server.   ccm.clm.example.org-node.webserver1.
    Note the path displayed for the generated plugin configuration file on Server 1 which is the IHS Server.

The following steps are performed on “Server1′ which hosts IHS.

9.3Merge plugin directives

We now need to merge in the appropriate sections from the plugin configuration generated for the CCM profile into the plugin configuration that contains the merged directives for the JTS, RM and QM profiles.
Remember that in step 8.5 we copied <path to plugin installdir>/config/webserver/plugin-cfg.xml to <path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml. Run the pluginCfgMerge tool to merge the contents of the new plugin-cfg.xml propagated from the CCM server. 
  wasinstall_root/bin/pluginCfgMerge.sh <path to plugin installdir>/config/webserver1/plugin-cfg.xml <path to plugin installdir>/config/webserver/rm-jts-qm-plugin-cfg.xml  <path to plugin installdir>/config/webserver/plugin-cfg.xml

9.4 Edit httpd.conf

Open the IHS httpd.conf file in a text editor and change the WebSpherePluginConfig directive to point to the merged plugin configuration file. 
WebSpherePluginConfig <path to plugin installdir>/config/webserver/plugin-cfg.xml"
Restart IHS.
First verify that you can still access the JTS, QM and RM pages using the IHS URL https://clm.example.org/jts, https://clm.example.org/rm and https://clm.example.org/qm.
Next verify that you can access the CCM page using the “internal” URL: https://ccmserver01.example.org:9449/ccm. and then  verify that the IHS URL https://clm.example.org/ccm displays the same page.

Running the JTS Setup wizard

Now that we have URLs that are server agnostic we can run the JTS setup wizard and use these URLs when registering the applications. Here are the discovery URLs that will be used:

Requirements Management: https://clm.example.org/rm/scr
Quality Management: https://clm.example.org/qm/scr
Change and Configuration Management: https://clm.example.org/ccm/scr
Lifecycle Project Administration: https://clm.example.org/admin/scr

Moving an application

Now suppose that we wish to redeploy the RM application to it’s own separate server (for example, rmserver01.example.org) without affecting users’ ability to access it through https://clm.example.org/rm. Here is a summary of the steps, previously detailed, to be repeated:
  1. Deploy the RM application to WAS on rmserver01.example.org
    Follow the instructions in the CLM Infocenter, making sure to copy over the directory that contains the indexes and configuration files, located at <JazzInstallDir>/server/conf/rm for the RM application from the original server.
  2. Setup SSL Handshake Between WAS profile on rmserver01.example.org and IHS on clm.example.org
    Follow the procedure detailed in Setup SSL Handshake Between the WAS profiles and IHS, creating a new “rmwaskeys.kdb” keystore from the new WAS profile, copying this keystore over to the IHS server and using gscmd to import it into the IHS keystore (ihskeys.kdb).
  3. Force WAS To Honor Host Headers
    Follow the procedure in Force WAS To Honor Host Headers on the new WAS profile hosting the RM application.
  4. Setup Single Sign-On(SSO) with WAS and import JTS keys
    Follow the procedure in Single Sign-On(SSO) with WAS to set the domain name and  import the keys from the jtsssokey key file.
  5. Configure WAS IHS Plug-in for the RM application
    Follow the procedure in Configure WAS IHS Plug-in for the CCM application (Server 3) to run the plugin configuration script for the RM profile and propagate the plugin configuration back to the IHS server
  6. Replace plugin directives and edit the httpd.conf
    Finally follow the procedure in Merge plugin directives , edit the httpd.conf file and restart IHS.

Using the Command line

Many of the steps documented carried out via the GUI or the WAS Admin Console also have command line or wasadmin equivalents listed below against the relevant section.
Section 1 : wsadmin AdminTask.createKeyStore and AdminTask.exportCertificate
Section 4 : wsadmin AdminConfig.list and AdminConfig.create
Section 5 : wsadmin AdminTask.configureSingleSignon and AdminTask.exportLTPAKeys
Sections 6 , 7, 8, 9 : Configuring a web server plug-in using the pct tool
Sections 6.1, 7.1 , 8.3 , 9.2 : GenPluginCfg command

References

  1. Collaborative Lifecycle Management 4.0.1 Information Center: Installation process and topology examples
  2. jazz.net: Moving Jazz Servers and URI Stability with CLM 2011
  3. Collaborative Lifecycle Management 4.0.1 Information Center: Reverse proxy servers in topologies
  4. WebSphere 8 Information Center
  5. Tip: Single Sign-on using WebSphere Application Server

Acknowledgement

Many thanks to Indradri Basu (IBM Rational, India) for helping with much of the WAS related content

About the author

Sudhakar is the Sydney, Australia based member of the the Jazz Jumpstart team which is a worldwide group of development specialists who bring new and advanced Jazz-based technologies to customers.
Please direct feedback and comments to sudhakar@au1.ibm.com

Copyright © 2013 IBM Corporation

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Fri, 10 May 2013