WPS 5.1 / TAM 5.1.0.2 Integration Guide
Volume I ‑ Installation and Configuration
1 INTRODUCTION
This document outlines an approach that can be used to build a system integrating WebSphere® Portal Server (WPS) and Tivoli® Access Manager (TAM).
The integration process described in this document assumes a single SuSE Linux Enterprise Server 8.0 OS.
These instructions do not address the use of SSL for LDAP access.
These instructions are based on the following product versions:
- IBM® WebSphere® Portal Server, Extend Edition, v5.0.2.1;
- IBM® Tivoli® Access Manager for e-Business, v5.1, fixpack 2;
- IBM® Directory Server, v5.2;
- IBM® WebSphere® Application Server, v5.0.2
WPS-TAM INTEGRATION
The basic steps in the integration are as follows:
- Install base WPS 5.0 system
- Includes install of WebSphere® Application Server
- No HTTP server integration
- No IBM® Directory Server integration
- Uses Cloudscape database
- Upgrade WPS 5.0 to WPS 5.0.2
- [Optional] Apply Cumulative Fix 1 for WPS 5.0.2
- Integrate IBM® HTTP Server with WPS
- Install and integrate IBM® Directory Server with WPS
- Using standard WPS LDAP object classes
- Install TAM 5.1 Base, WPM, and LDAP Web Administration Tool
- WPM and LDAP Web Admin Tool install methods are for demo/test purposes only
- [Optional] Apply fixpack 2 to TAM 5.1
- Configure WPS for SSL
- WPS then listens on 2 ports
- “/wps/portal” over HTTP
- “/wps/myportal” over HTTPS
- Install TAM 5.1 WebSEAL
- [Optional] Apply fixpack 2 to TAM 5.1 WebSEAL
- Integrate Authentication
- WebSEAL integration is now always required ‑ we use 2 junctions (one HTTP, one HTTPS)
- Replace portal login pages etc to allow Login/Logout buttons to work in integrated system
- Configure Trust Association Interceptor in WebSphere® Application Server
- [Optional] Integrate JAAS Authentication
- [Optional] Integrate Credential Vault
- Allows WPS to use TAM GSO Lockbox as the backing store for the WPS Credential Vault
- Requires “Integrate JAAS Authentication” step to be done first.
- [Optional] Integrate Authorization
- Allows WPS to externalize access control for specific resources to TAM.
- Requires “Integrate JAAS Authentication” step to be done first.
See also: WPS Configuration Utility for a Secure Portal on IBM® AlphaWorks.
Install and Integrate IBM® Directory Server
Uninstall Existing LDAP Packages
Before installing the IBM® Tivoli® Directory Server, we need to remove any conflicting LDAP packages that are already installed on the system.
Determine which LDAP packages are already installed:
# rpm -qa | grep ldapopenldap2-client-2.1.4-48
nss_ldap-199-53
pam_ldap-150-79
openldap2-2.1.4-48
yast2-ldap-client-2.6.5-122
List any dependent packages:
# rpm -e --test openldap2-client-2.1.4-48 nss_ldap-199-53 pam_ldap-150-79 openldap2-2.1.4-48 yast2-ldap-client-2.6.5-122
The “openldap2-client-2.1.4-48” package is a prerequisite for a large number of other packages so it was left on the system. There were no dependent packages for the other LDAP related packages. These other packages were removed using the following command
# rpm -e nss_ldap-199-53 pam_ldap-150-79 openldap2-2.1.4-48 yast2-ldap-client-2.6.5-122
According to the TAM 5.1 documentation, if we decide to leave the “openldap2-client-2.1.4-48” package on the system, we need to replace the OpenLDAP client commands in “/usr/bin” with symbolic links to the IBM® Tivoli® Directory equivalent commands.
Create the file:
/home/amsterdam/ln.ldap.commands.ksh
... with the following contents:
ln -s -b -f /usr/ldap/bin/ldapmodify /usr/bin/ldapadd
ln -s -b -f /usr/ldap/bin/ldapdelete /usr/bin/ldapdelete
ln -s -b -f /usr/ldap/bin/ldapmodify /usr/bin/ldapmodify
ln -s -b -f /usr/ldap/bin/ldapmodrdn /usr/bin/ldapmodrdn
ln -s -b -f /usr/ldap/bin/ldapsearch /usr/bin/ldapsearch
Now execute the command file as follows (commands are shown in bold). Note that the “-b” option on the above commands will create a backup of the files being replaced by the symbolic links.
# /home/amsterdam/ln.ldap.commands.ksh
2.5.3 Install the Packages for DB2, GSKIT and LDAP
Load the Directory Server CD (for Linux) that ships with TAM 5.1 ‑ this CD contains IBM® Tivoli® Directory Server version 5.2 and its prerequisites (DB2 and GSKIT).
Mount the CD using the following command :
# mount /dev/cdrom /media/cdrom
Change to the location of the package files and load the packages for DB2, GSKIT and LDAP as follows (commands shown in bold):
# cd /media/cdrom/xSeries
# rpm -ivh IBM_db2*.rpm gsk7bas-7.0-1.9.i386.rpm ldap-clientd-5.2-1.i386.rpm ldap-serverd-5.2-1.i386.rpm
2.5.4 Install TAM Patch for the Directory Server
Change directory to the root directory of the Directory Server CD (for Linux) that ships with TAM 5.1, and execute the Access Manager patch for the Directory Server as follows (commands shown in bold):
# cd /media/cdrom
# ./am_update_ldap.sh
2.5.5 Update DB2 License
The DB2 license that ships with IBM® Directory Server is a 3-month evaluation license. In order to avoid future problems with your test system, it is recommended that you update the license to one that won’t expire. A suitable license is shipped on the “Access Manager Directory Server for Solaris” CD (which is part of the TAM 5.1 distribution set) at the location “solaris/db2ese.lic” relative to the root directory of the CD. [Note: A copy of this file is contained in the ZIP archive embedded in this document].
As a first step, we will display the current license as follows (commands are shown in bold):
# /opt/IBM/db2/V8.1/adm/db2licm -l
Product Name = "DB2 Enterprise Server Edition"
Product Password = "DB2ESE"
Version Information = "8.1"
Expiry Date = "05/31/04 (Try & Buy)"
Registered Connect User Policy = "Disabled"
Number Of Entitled Users = "5"
Enforcement Policy = "Soft Stop"
Number of processors = "1"
Number of licensed processors = "1"
Annotation = ""
Other information = ""
Note that the output above shows some future date as the expiry date.
Assuming that the updated license file (“db2ese.lic”) is located in “/home/amsterdam”, update the DB2 license as follows (commands are shown in bold):
# /opt/IBM/db2/V8.1/adm/db2licm /home/amsterdam/db2ese.lic
DBI1402I License added successfully.
DBI1426I This product is now licensed for use as specified in
the License Acceptance and License Information
documents pertaining to the licensed copy of this
product. USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF
THE TERMS OF THE IBM® LICENSE ACCEPTANCE AND LICENSE
INFORMATION DOCUMENTS, LOCATED IN THE FOLLOWING
DIRECTORY: /opt/IBM/db2/V8.1/license/C
Now rerun the command to display the current license as follows (commands are shown in bold):
# /opt/IBM/db2/V8.1/adm/db2licm -l
Product Name = "DB2 Enterprise Server Edition"
Product Password = "DB2ESE"
Version Information = "8.1"
Expiry Date = "Permanent"
Registered Connect User Policy = "Disabled"
Number Of Entitled Users = "5"
Enforcement Policy = "Soft Stop"
Number of processors = "1"
Number of licensed processors = "1"
Annotation = ""
Other information = ""
Note that the Expiry Date value is now shown as “Permanent”.
2.5.6 Configure the IBM® Tivoli® Directory Server
Create LDAP DB2 User on OS-level
- Create a UNIX group call "other"...
groupadd other
- Make user "root" a member of the "other" group Locate and select the check box next to the “root”
- Create a user with the following qualities...
First Name LDAP LDAP Name Server User login ldapdb2 Home directory /home/ldapdb2 Login shell /usr/bin/ksh Default group other Run the LDAP Configuration Utility
Run the Directory Server Configuration Utility...
# ldapxcfg
The following screen should then appear.
Select the “Administrator DN/password” entry in the left-hand navigation panel.
Enter the following field values:
Administrator cn=root (Password fields) passw0rd Press “OK” to set the administrator userid and password.
Press “OK” to continue.
Select the “Configure database” entry in the left-hand navigation panel.
Ensure the “Create a new database” radio button is selected and press the “Next” button to continue.
Enter the following field values:
User ID ldapdb2 Password passw0rd Press “Next” to continue.
Enter “ldapdb2” in the “Database name” field and press “Next” to continue.
Ensure the “Create a universal DB2 database (UTF-8/UCS-2)” radio button is selected and press the “Next” button to continue.
Enter “/home/ldapdb2” in the “Database location” field and press “Next” to continue.
Press the “Finish” button to start the configuration of the database.
The progress screen shown above will be displayed during the configuration.
Once the configuration is complete, the message “IBM® Tivoli® Directory Server Configuration Complete” will appear in the message panel.
Press “Close” to complete the database configuration step.
While we have the Directory Configuration program running, we will add the LDAP Suffixes that we will need later in the integration.
Select the “Manage suffixes” button in the left-hand navigation panel.
Enter “dc=ibm,dc=com” in the “Suffix DN” field and press the “Add” button.
Enter “secAuthority=Default” in the “Suffix DN” field and press the “Add” button.
The two new suffixes should now appear in the list. Press “OK” to continue.
Select the “File->Close” entry from the menu in the top left-hand corner to close the Directory Configuration utility.
2.5.6.3 Start the IBM® Directory Server
To check the run-state of the IBM® Tivoli® Directory Server, enter the following command
# /usr/ldap/bin/ibmdirctl -D cn=root -w passw0rd status
The server should be stopped following the configuration, and as such, the result of the status command should be:
ibmslapd process is not running.
Start the IBM® Tivoli® Directory Server using the following command
# /usr/ldap/bin/ibmdirctl -D cn=root -w passw0rd start
Note that the server will take longer to start if the DB2 instance also needs to be started (which will be done automatically when you start the Directory Server). If you check the status of the server while it is still starting you will see the following status message.
ibmslapd process is starting.
Once the server has been started the status messages changes to:
ibmslapd process is running.
For completeness, the command to stop the Directory Server is as follows (but do not execute this command at this time as we need the server running for subsequent steps):
# /usr/ldap/bin/ibmdirctl -D cn=root -w passw0rd stop
2.5.7 Import WPS Users Into The IBM® Directory Server
Access Manager has traditionally required specific object classes for defining users and groups in LDAP:
· “ePerson” for users;
· “accessGroups” for groups.
With Access Manager version 5.1, these object classes are still the only ones that can be created using the TAM command line, API or GUI administration utilities. However, you can now “import” users and groups from other object classes into TAM. TAM uses the term “import” to describe the addition of an auxiliary class to the user/group entry and other steps required to effectively TAM-enable the user, so that the user can authenticate to TAM WebSEAL (or other TAM components).
We will be taking this new approach in this document. This means that we cannot use the TAM user/group administration utilities to create users or groups ‑ we will create them outside of TAM and “import” them into TAM. However, it does also mean that we can now use the default object classes for WAS and WPS (which makes the integration a little simpler). If you want to adopt the more traditional approach of using TAM-specific object classes, you will need to modify WAS and WPS to use these classes. Refer to the documentation associated with these products for information on how to modify user/group object classes and search filters.
We will now import the administrator userids and group used by WebSphere® Portal Server into the IBM® Directory Server.
Load the WebSphere® Portal Setup CD and copy the LDIF template to our temporary directory, as follows (commands are shown in bold):
# mount /dev/cdrom /media/cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
# cp /media/cdrom/PortalUsers.ldif /home/amsterdam
# umount /media/cdrom
Edit the file “/home/amsterdam/PortalUsers.ldif” as follows:
· Replace all occurrences of “yourco” with “ibm” (to match the DN structure we will be using in this document)
· Change the “userpassword” fields for “wpsadmin” and “wpsbind” to be “passw0rd” (to match our password convention for this document).
[Note: A modified version of this file is in the ZIP archive embedded in this document]
Import the standard WPS userids and group to the IBM® Directory Server as follows (commands are shown in bold):
# ldapadd –D cn=root –w passw0rd –c –f /home/amsterdam/PortalUsers.ldif adding new entry dc=ibm,dc=com adding new entry cn=users,dc=ibm,dc=com adding new entry cn=groups,dc=ibm,dc=com adding new entry uid=wpsadmin,cn=users,dc=ibm,dc=com adding new entry uid=wpsbind,cn=users,dc=ibm,dc=com adding new entry cn=wpsadmins,cn=groups,dc=ibm,dc=com
2.5.8 Configure the WebSphere® Portal Server for LDAP
2.5.8.1 Edit “wpconfig.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/config/wpconfig.properties:…
# WasUserid: The user ID for WebSphere® Application Server security authentication
# CUR: WasUserid=wpsbind
# See LDAP examples below:
# IBM® Directory Server: { uid=wpsbind,cn=users,dc=yourco,dc=com }
# Domino: { cn=wpsbind,o=yourco.com }
# Active Directory: { cn=wpsbind,cn=users,dc=yourco,dc=com }
# SunOne: { uid=wpsbind,ou=people,o=yourco.com }
# Novell eDirectory { uid=wpsbind,ou=people,o=yourco.com }
WasUserid=uid=wpsbind,cn=users,dc=ibm,dc=com
# WasPassword: The password for WebSphere Application Server security authentication (LDAP and CUR)
WasPassword=passw0rd
…
# PortalAdminId: The user ID for the WebSphere Portal Administrator
# DEV (No security): PortalAdminId=uid=<portaladminid>,o=default organization
# CUR: PortalAdminId=uid=<portaladminid>,o=default organization
# See LDAP examples below:
# IBM® Directory Server: { uid=<portaladminid>,cn=users,dc=yourco,dc=com }
# Domino: { cn=<portaladminid>,o=yourco.com }
# Active Directory: { cn=<portaladminid>,cn=users,dc=yourco,dc=com }
# SunOne: { uid=<portaladminid>,ou=people,o=yourco.com }
# Novell eDirectory { uid=<portaladminid>,ou=people,o=yourco.com }
PortalAdminId=uid=wpsadmin,cn=users,dc=ibm,dc=com
…
# PortalAdminPwd: The password for the WebSphere Portal Administrator
PortalAdminPwd=passw0rd
# PortalAdminGroupId: The group ID for the WebSphere Portal Administrator group
# DEV (No security): PortalAdminGroupId=cn=wpsadmins,o=default organization
# CUR: PortalAdminGroupId=cn=wpsadmins,o=default organization
# See LDAP examples below:
# IBM® Directory Server: { cn=wpsadmins,cn=groups,dc=yourco,dc=com }
# Domino: { cn=wpsadmins }
# Active Directory: { cn=wpsadmins,cn=groups,dc=yourco,dc=com }
# SunOne: { cn=wpsadmins,ou=groups,o=yourco.com }
# Novell eDirectory { cn=wpsadmins,ou=groups,o=yourco.com }
PortalAdminGroupId=cn=wpsadmins,cn=groups,dc=ibm,dc=com
…
# LTPAPassword: Specifies the password to encrypt and decrypt the LTPA keys.
LTPAPassword=passw0rd
…
# SSODomainName: Specifies the domain name (.ibm.com, for example) for all Single Sign-on hosts.
SSODomainName=ibm.com
…
# LDAPHostName: The LDAP server hostname
LDAPHostName=amsterdam.ibm.com
…
# LDAPAdminPwd: The LDAP administrator password
LDAPAdminPwd=passw0rd
…
#LDAPBindID: The user ID for LDAP Bind authentication
# See LDAP examples below:
# IBM® Directory Server: { uid=wpsbind,cn=users,dc=yourco,dc=com }
# Domino: { cn=wpsbind,o=yourco.com }
# Active Directory: { cn=wpsbind,cn=users,dc=yourco,dc=com }
# SunOne: { uid=wpsbind,ou=people,o=yourco.com }
# Novell eDirectory { uid=wpsbind,ou=people,o=yourco.com }
LDAPBindID=cn=root
#LDAPBindPassword: The password for LDAP Bind authentication
LDAPBindPassword=passw0rd
…
WmmSystemId=uid=wpsbind,cn=users,dc=ibm,dc=com
WmmSystemIdPassword=passw0rd
…
# LDAPSuffix: The LDAP suffix appropriate for your LDAP server
# IBM® Directory Server: { dc=yourco,dc=com }
# Domino value is null
# Domino: { }
# Active Directory: { dc=yourco,dc=com }
# SunOne: { o=yourco.com }
# Novell eDirectory { o=yourco.com }
LDAPSuffix=dc=ibm,dc=com
…
2.5.8.2 Run WebSphere® Portal Server Configuration Program
Ensure the IBM® HTTP Server is running.
Run the WebSphere® Portal Server configuration program to validate the LDAP configuration (commands are shown in bold):
# cd /opt/WebSphere/PortalServer/config
# ./WPSconfig.sh validate-ldap
Licensed Materials - Property of IBM
5724-E76, 5724-E77
(C) Copyright IBM® Corp. 2001, 2003 All Rights Reserved.
Running WebSphere® Portal 5.0.2.0 configuration
…
BUILD SUCCESSFUL
Total time: 1 minute 11 seconds
Once the validation of the LDAP configuration is complete, you should see a “BUILD SUCCESSFUL” message, as shown above. If not, check the changes made to the “wpconfig.properties” file.
If the validation step completed successfully, run the WebSphere® Portal Server configuration program to configure WPS for LDAP, as follows (commands are shown in bold):
# cd /opt/WebSphere/PortalServer/config
# ./WPSconfig.sh enable-security-ldap
Licensed Materials - Property of IBM
5724-E76, 5724-E77
(C) Copyright IBM® Corp. 2001, 2003 All Rights Reserved.
Running WebSphere® Portal 5.0.2.0 configuration
…
BUILD SUCCESSFUL
Total time: 60 minutes 6 seconds
[Note that the execution of this command may take a while]
Once the WebSphere® Portal Server configuration is complete, confirm the existence of a “BUILD SUCCESSFUL” message, as shown above.
2.5.8.3 Test the Configuration
Display the URL http://amsterdam.ibm.com/wps/portal in a browser window.
Press the “Log in” link in the top left-hand corner of the screen.
Enter “wpsadmin” and “passw0rd” in the User ID and Password fields and press “Log in”.
Press the “Log out” link to return to the public portal page.
Close the browser window.
2.6 Install and Configure Access Manager Base
In this section, we will install and configure both the Base and Web Administration packages for IBM® Tivoli® Access Manager version 5.1. We will leave the Web Security package until after we have moved the IBM HTTP Server from port 80.
Note that since we are setting up a demonstration/test system in this document, we will not configure Access Manager to communicate with the IBM® Directory Server over SSL. Production deployments should of course use SSL for all communication with the IBM® Directory server. Refer to the IBM® Tivoli® Access Manager documentation for instructions on the configuration of SSL with the IBM® Directory Server.
2.6.1 Install Access Manager 5.1 Base Packages
Load the Access Manager 5.1 Base CD. Install the Access Manager Base packages as follows (commands are shown in bold):
# mount /dev/cdrom /media/cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
# cd /media/cdrom/xSeries/
# rpm -ivh PDAcld-PD-5.1.0-0.i386.rpm PDJrte-PD-5.1.0-0.i386.rpm PDMgr-PD-5.1.0-0.i386.rpm PDRTE-PD-5.1.0-0.i386.rpm
adding ivmgr user
adding tivoli user
PDRTE-PD ##################################################
PDAcld-PD ##################################################
PDJrte-PD ##################################################
PDMgr-PD ##################################################
# cd /
# umount /media/cdrom
2.6.2 Configure Access Manager 5.1 Base Packages
We will now configure the Access Manager base packages. Run the Access Manager configuration program as follows (commands are typed in bold):
# pdconfig
The Access Manager configuration program is a command line program. The first menu should be as follows:
Tivoli® Access Manager Setup Menu
1. Configure Package
2. Unconfigure Package
3. Display Configuration Status
x. Exit
Select the menu item [x]:
Enter “1” and press the Enter key.
Tivoli® Access Manager Configuration Menu
1. Access Manager Runtime Configuration
2. Access Manager Policy Server Configuration
3. Access Manager Authorization Server Configuration
4. Access Manager Java Runtime Environment Configuration
x. Return to the Tivoli Access Manager Setup Menu
Select the menu item [x]:
Enter “1” and press the Enter key.
Tivoli® Common Directory logging is not configured.
This scheme provides a common location for log files for Tivoli® products instead of separate locations determined by each application.
Do you want to use Tivoli® Common Directory logging (y/n) [No]:
Press the Enter key to accept the default of not using Tivoli® Common Logging.
Log files for this application will be created in directory: /var/PolicyDirector/log
1. LDAP
Registry [1]:
Press the Enter key to accept the default Registry type (LDAP).
LDAP server host name: amsterdam.ibm.com
Enter the LDAP server host name (“amsterdam.ibm.com”).
LDAP server port [389]:
The package has been configured successfully.
Press Enter to continue.
Press Enter to return to the configuration menu.
Use a similar process to that above, configure the following packages and associated parameter values using the Access Manager Configuration Utility:
· Access Manager Policy Server
LDAP administrator ID cn=root LDAP administrator password passw0rd SSL between Policy Server and LDAP? no TAM administrator password passw0rd Policy server SSL port 7135 SSL certificate lifecycle 365
· Access Manager Authorization Server
SSL between Policy Server and LDAP) no Domain Default Policy server host name amsterdam.ibm.com Policy server SSL port 7135 Administrator ID sec_master Administrator password passw0rd Local host name amsterdam.ibm.com Administration request port 7137 Authorization request port 7136
· Access Manager Java Runtime Environment
Full path of JRE /opt/WebSphere/AppServer/java/jre Full or Standalone full Hostname of Policy Server amsterdam.ibm.com Port for Policy Server 7135 Policy Server Domain Default Tivoli® Common Directory Logging? no
2.6.3 [Optional] Apply Fixpack 2 for Tivoli® Access Manager 5.1
Tivoli® Access Manager 5.1 Java Runtime is missing some classes required by WebSphere® Portal Server to externalize authorization of portal resources to Access Manager. Fixpack 2 for TAM 5.1 contains a fix that corrects this problem. So if you intend to configure externalize WPS resources to TAM, this fix pack is required. The only exception is if there is no other TAM (version 5.1) components running on the machine where your WPS server is deployed; in which case, you can optionally choose to install a TAM version 4.1 Java Runtime on the WPS machine. Personally, I would only take this option if for some reason there was no chance of upgrading to TAM 5.1 fixpack 2.
If you do not intend to configure externalization of WPS resources to TAM, you can decide whether or not to install this fixpack; however, there are a number of bug fixes in the fixpack that will more than likely make it worthwhile ‑ especially since it will take relatively little effort and time to apply the fixpack.
The first step is to stop the Access Manager servers as follows (commands are shown in bold):
# pd_start stop
Stopping the: Access Manager Policy Server
Stopping the: Access Manager Authorization Server
2.6.3.1 Update GSKIT to Version 7.0.1.16
Before installing TAM 5.1 fixpack 2, we need to update the IBM® Global Security Toolkit (GSKit) to version 7.0.1.16
To obtain the updated GSKit installation package, contact IBM® Customer Support for download locations. Contact information can be obtained at the following URL:
http://techsupport.services.ibm.com/guides/tivoli_contacts.html
The following instructions assume you have downloaded the GSKIT installation file for SUSE 8 on X-Series (“gsk7bas_295-7.0-1.16.i386.rpm”) to “/tmp”.
Install the updated version of GSKIT as follows (commands are shown in bold):
# cd /tmp
# rpm -Uvh --noscripts gsk7bas_295-7.0-1.16.i386.rpm
gsk7bas ##################################################
Verify the update of GSKIT as follows (commands are shown in bold):
# gsk7ver
SYS
============
@(#)CompanyName: IBM® Corporation
@(#)LegalTrademarks: IBM
@(#)FileDescription: IBM® Global Security Toolkit
@(#)FileVersion: 7.0.1.16
@(#)InternalName: gsksys
…
Confirm that the value of “FileVersion” for all of the components is “7.0.1.16”.
2.6.3.2 Upgrade Base TAM Packages to Version 5.1.0.2
Fixpack 2 for TAM 5.1 can be downloaded from the following URL:
http://www3.software.ibm.com/ibmdl/pub/software/tivoli_support/patches/patches_5.1/
The following instructions assume you have downloaded the fixpack installation file for SUSE 8 on X-Series (“5.1-TAM-FP02-LIN.tar”) to “/tmp”.
Unpack and install the fixpack as follows (commands are shown in bold):
# mkdir /tmp/tam51fp2
# cd /tmp/tam51fp2
# tar xvf /tmp/5.1-TAM-FP02-LIN.tar
PDAcld-PD-5.1.0-2.i386.rpm
PDAuthADK-PD-5.1.0-2.i386.rpm
PDJrte-PD-5.1.0-2.i386.rpm
PDMgr-PD-5.1.0-2.i386.rpm
PDMgrPrxy-PD-5.1.0-2.i386.rpm
PDRTE-PD-5.1.0-2.i386.rpm
PDWPM-PD-5.1.0-2.i386.rpm
# rpm -Uvh PDAcld-PD-5.1.0-2.i386.rpm PDJrte-PD-5.1.0-2.i386.rpm PDMgr-PD-5.1.0-2.i386.rpm PDMgrPrxy-PD-5.1.0-2.i386.rpm PDRTE
-PD-5.1.0-2.i386.rpm PDWPM-PD-5.1.0-2.i386.rpmPDRTE-PD ##################################################
PDAcld-PD ##################################################
PDJrte-PD ##################################################
To upgrade Access Manager Java Runtime Environment,
please do the following steps.
1. Ensure that Java Version 1.3.1 is installed and is the first in PATH.
2. Run /opt/PolicyDirector/sbin/pdjrteupg.
PDMgr-PD ##################################################
PDMgrPrxy-PD ##################################################
PDWPM-PD ##################################################
Verify the versions of TAM installed as follows (commands are shown in bold):
# pdversion
IBM® Tivoli® Access Manager Runtime 5.1.0.2
IBM® Tivoli® Access Manager Policy Server 5.1.0.2
IBM® Tivoli® Access Manager Web Portal Manager 5.1.0.2
IBM® Tivoli® Access Manager Authorization Server 5.1.0.2
IBM® Tivoli® Access Manager Java Runtime Environment 5.1.0.2
IBM® Tivoli® Access Manager Policy Proxy Server 5.1.0.2
Confirm that the product level shown for all components is now “5.1.0.2”.
Restart the Access Manager servers as follows (commands are shown in bold):
# pd_start restart
Stopping the: Access Manager Policy Server
Stopping the: Access Manager Authorization Server
Starting the Access Manager Policy Server
Starting the Access Manager Authorization Server
2.6.3.3 Upgrade TAM Java Runtime
We now need to upgrade our TAM Java Runtime instance that is configured for the WebSphere® Application Server. However, the instructions shown earlier in the output of the RPM command we used to upgrade the TAM components did not work in the test system used to create this document. So we will use a slightly more manual approach.
Stop the application servers “server1” and “WebSphere_Portal”, as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh server1 -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/stopServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind
-password passw0rdADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
Note that since we have now enabled security in WebSphere Application Server (as part of configuring WPS for LDAP), we now need to supply a userid and password to the “stopServer.sh” command. A userid is also now required for the “serverStatus.sh” command, but not the “startServer.sh” command.
Update the TAM Java Runtime that is configured for the WebSphere® Application Server as follows (commands are shown in bold):
# cp /opt/PolicyDirector/java/export/pdjrte/PD.jar /opt/WebSphere/AppServer/ja
va/jre/lib/ext/PD.jar# chmod 644 /opt/WebSphere/AppServer/java/jre/lib/ext/PD.jar
Restart the application servers “server1” and “WebSphere_Portal”, as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 13722
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 14371
At this point, you may want to login and logout of WPS to confirm it started correctly ‑ as we did earlier after we had installed the WPS cumulative patch.
2.7 Configure WebSphere® Portal Server for SSL
The integration described in this document is based on using a WebSphere® Portal Server that has been configured for SSL. When WebSphere® Portal Server is configured in this manner, public portal pages (i.e. /wps/portal/*) can still be accessed over HTTP, but private pages (i.e. /wps/myportal/*) can only be accessed via HTTPS. Other approaches maybe possible, but the two-junction approach is the only one addressed in this document.
In this section we will configure WebSphere® Portal Server to listen on ports 81 and 444, as we will leave ports 80 and 443 for the WebSEAL server. If you are installing WebSEAL and the WebSphere® Portal Server on different machines, you can leave the WebSphere® Portal ports at 80 and 443 if you prefer.
Important Note: By default, WPS POST’s userids and passwords over HTTP, even where HTTPS has been configured. The switch to HTTP is done after the userid and password has been posted. The WebSphere® Portal Server InfoCenter describes how to modify various JSPs in each theme to correct this problem. However, these changes should not be done here, as they conflict with the junction options used. The use of WebSEAL negates the need for these changes anyway, as the WPS login screen is no longer used once WebSEAL is configured to protect the WPS application.
2.7.1 Create a New Key Ring for the IBM® HTTP Server
Create a new directory “/opt/IBMHttpServer/keytab“ and start the IBM® Key Management Utility as follows (commands are in bold):
# mkdir /opt/IBMHttpServer/keytab
# cd /opt/IBMHttpServer/keytab
# . /opt/WebSphere/AppServer/bin/setupCmdLine.sh
# gsk7ikm
Select “Key database File->New…” from the menu bar.
Ensure “CMS key database file” is selected from the pull-down list. Enter the following field values, and press “OK” to continue:
· File Name ihs.kdb
· Location /opt/IBMHttpServer/keytab
Enter “passw0rd” in the password fields. Select the “Stash the password to a file?” check box and press “OK” to continue.
Press “OK” to continue.
Select “Create->New Self-Signed Certificate” from the menu bar.
Enter the following field values and press “OK” to create a new self-signed certificate.
· Key Label IHS
· Version X509 V3
· Key Size 1024
· Common Name amsterdam.ibm.com
· Organization IBM
· Country US
· Validity Period 365
Later we will need the certificate for the Certification Authority that signed our self-signed certificate, so we will export it now while we have the keystore open.
Press the “Extract Certificate…” button.
Enter the following field values and press “OK” to extract the CA certificate.
· Data type Base64-encoded ASCII data
· Certificate file name ihs.arm
· Location /opt/IBMHttpServer/keytab/
Once the certificate has been extracted, close the IBM® Key Management Utility.
2.7.2 Configure IBM® HTTP Server for SSL
Modify the values shown in bold below in
/opt/IBMHttpServer/conf/httpd.conf:…
LoadModule unique_id_module libexec/mod_unique_id.so
LoadModule setenvif_module libexec/mod_setenvif.so
#LoadModule vhost_alias_module libexec/mod_vhost_alias.so
LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so
…
AddModule mod_unique_id.c
AddModule mod_setenvif.c
#AddModule mod_vhost_alias.c
AddModule mod_ibm_ssl.c
…
# Port: The port to which the standalone server listens. For
# ports < 1023, you will need httpd to be run as root initially.
#
Port 81
# The following Listen directive is really only needed if you have
# another Listen directive enabled in the config file, but it
# does not cause harm to have it in anyway.
Listen 81
…
WebSpherePluginConfig /opt/WebSphere/AppServer/config/cells/plugin-cfg.xml
Listen 444
<virtualhost *:444>
SSLEnable
Keyfile "/opt/IBMHttpServer/keytab/ihs.kdb"
SSLV2Timeout 100
SSLV3Timeout 1000
</virtualhost>
[Note: A modified copy of this file is in the ZIP archive embedded in this document]
2.7.2.1 Test IBM® HTTP Server Configuration
Stop and restart the IBM HTTP Server, as follows (commands are shown in bold):
# /opt/IBMHttpServer/bin/apachectl stop
/opt/IBMHttpServer/bin/apachectl stop: httpd stopped
# /opt/IBMHttpServer/bin/apachectl start
/opt/IBMHttpServer/bin/apachectl start: httpd started
Display the following URL in a browser: http://amsterdam.ibm.com:81.
Confirm that the IBM® HTTP Server welcome page is displayed – as shown above.
Display the following URL in a browser: https://amsterdam.ibm.com:444.
If you are using Mozilla as your browser, you will then see the following screen. Other browser types may display a similar screen.
Select the “Accept this certificate permanently” and press “OK” to accept the (self-signed) server certificate presented by the IBM® HTTP Server.
Confirm that the IBM® HTTP Server welcome page is displayed.
2.7.3 4Configure New Virtual Host in WebSphere® Application Server
Start the application server “server1” as follows (commands are in bold):
# /opt/WebSphere/AppServer/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 1532
Open the WebSphere® Administration Console: https://amsterdam.ibm.com:9043/admin
Note: Since security has now been enabled in the WebSphere® Application Server, the console is now accessed over HTTPS. If you enter the HTTP URL that is used prior to security being enabled, it should redirect to the HTTPS URL.
Enter “wpsbind” and “passw0rd” the “User ID” and “Password” fields (respectively) and press “OK” to continue.
Expand the “Environment” entry and select the “Virtual Hosts” link in the left-hand navigation panel.
Select the “default_host” link.
Select the “Host Aliases” link in the Additional Properties panel.
Select the checkbox associated with port 80.
Press the “Delete” button to remove the port 80 entry.
Press the “New” button.
Enter the following field values:
· Host Name *
· Port 81
Press “OK” to continue.
Select the “Host Aliases” link in the Additional Properties panel.
Press the “New” button.
Enter the following field values:
· Host Name *
· Port 444
Press “OK” to continue.
Press the “Save” link in the Message(s) Panel.
Press the “Save” button to commit the changes.
Select the “Update Web Server Plugin” link.
Press “OK” to update the web server plug-in.
Once the web-server plug-in has been generated, a message will appear in the Message(s) Panel.
Press the “Logout” button and close the browser.
Stop and restart the application server “server1”, as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh server1 -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/stopServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 7137
Stop and restart the IBM HTTP Server as follows (commands are shown in bold).
# /opt/IBMHttpServer/bin/apachectl stop
/opt/IBMHttpServer/bin/apachectl stop: httpd stopped
# /opt/IBMHttpServer/bin/apachectl start
/opt/IBMHttpServer/bin/apachectl start: httpd started
2.7.3.1 Test WebSphere® Application Server Configuration
Display the following URL in a browser: http://amsterdam.ibm.com:81/snoop.
As security has been enabled in WebSphere® Application Server, authentication is required for the snoop servlet. Enter “wpsadmin” and “passw0rd” in the “User Name” and “Password” fields of the Basic Authentication pop-up window and press “OK” to continue.
Confirm that the output from the snoop servlet is displayed – as shown above.
Scroll down to the “User Principal” field.
Confirm that the value for “User Principal” is “wpsadmin”.
Display the following URL in a browser: https://amsterdam.ibm.com:444/snoop.
Confirm that the output from the snoop servlet is displayed – without being prompted for authentication. Scroll down to the “User Principal” field and confirm the value is “wpsadmin”.
Note that the snoop servlet displayed earlier has written an LTPA cookie to the browser, so we are not required to authenticate when we access the snoop servlet again (unless the browser was closed between the two invocations, or the credential in the LTPA cookie has expired).
2.7.4 Configure WebSphere® Portal Server for SSL
Modify the values shown below in bold in the file:
“/opt/WebSphere/PortalServer/shared/app/config/services/ConfigService.properties”:
# The parameters of the (virtual) host that the portal is accessed through
#
# Default: localhost (host.name)
host.name =amsterdam.ibm.com
host.port.http =81
host.port.https =444
…
Stop and restart the WebSphere® Portal Server as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind
-password passw0rdADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 1900
2.7.5 Update WebSphere® Portal Configuration File
In order to avoid any subsequent problems with applying patches to our system, we will update the configuration file used by the WPS configuration utility to reflect the new port number for direct HTTP access to WPS.
Modify the values shown in bold below in the following configuration file:
/opt/WebSphere/PortalServer/config/wpconfig.properties…
# WpsHostPort: The port used by WebSphere® Portal
# For example: http://<WpsHostName>:<WpsHostPort>/<WpsContextRoot>/<WpsDefaultHome>
# For example "80" in the URL: http://localhost:80/wps/portal
WpsHostPort=81
…
2.7.5.1 Test WebSphere® Portal Server Configuration
Close all browser windows. Open a new browser window and display the following URL in a browser: http://amsterdam.ibm.com:81/wps/portal.
Confirm that public portal page is displayed and that it was accessed over HTTP using port 81.
Click the “Log in” link in the top right corner of the portal page to log in to WebSphere® Portal.
Enter “wpsadmin” and “passw0rd” in the userid and password fields and press the “Log in” button.
Note: Observe that the userid and password entered above is POST’ed over HTTP ‑ we will remove this security exposure later when we configure WebSEAL in front of the WebSphere® Portal Server and pass Single Sign-On (SSO) information from WebSEAL to WebSphere® Portal Server; thereby avoiding this screen and its potential security problem.
Depending on the brand of browser and security settings you are using, you may see a warning that the page contains mixed content. This occurs because the main portal page is accessed over HTTPS but the news, stocks, and weather portlets access content over HTTP. If a mixed content warning screen does appear, accept the warning to allow the private portal page to be displayed.
Confirm that the private portal page for “wpsadmin” is displayed and that it has been accessed over HTTPS using port 444. Click the “Log out” link in the top right corner of the portal page to logoff from WebSphere® Portal.
Confirm that public portal page is once again displayed and that it was accessed over HTTP, using port 81.
2.8 Install and Configure Access Manager WebSEAL
2.8.1 Install TAM WebSEAL 5.1 Package
Load the Access Manager 5.1 Web Security CD. Install the Access Manager WebSEAL as follows (commands are shown in bold):
# mount /dev/cdrom /media/cdrom
mount: block device /dev/cdrom is write-protected, mounting read-only
# cd /media/cdrom/xSeries/
# rpm -ivh PDWebRTE-PD-5.1.0-0.i386.rpm PDWeb-PD-5.1.0-0.i386.rpm
PDWebRTE-PD ##################################################
PDWeb-PD ##################################################
# cd /
# umount /media/cdrom
2.8.2 Configure Access Manager 5.1 WebSEAL Packages
We will now configure the Access Manager WebSEAL packages. Run the Access Manager configuration program as follows (commands are typed in bold):
# pdconfig
The Access Manager configuration program is a command line program. The first menu should be as follows:
Tivoli® Access Manager Setup Menu
1. Configure Package
2. Unconfigure Package
3. Display Configuration Status
x. Exit
Select the menu item [x]:
Enter “1” and press the Enter key.
Tivoli® Access Manager Configuration Menu
1. Access Manager WebSEAL Configuration
2. Access Manager Java Runtime Environment Configuration
x. Return to the Tivoli Access Manager Setup Menu
Select the menu item [x]:
Enter “1” and press the Enter key.
Access Manager WebSEAL Setup Menu
1. Configure
2. Unconfigure
3. Display Configuration Status
x. Return to Access Manager Setup Menu
Please select the menu item [x]:
Enter “1” and press the Enter key.
Enter WebSEAL instance name [default]:
Press the Enter key to accept the default WebSEAL instance name.
Use logical network interface (y/n) [n]?
Press the Enter key to accept default of not using a logical network interface.
Enter WebSEAL hostname [amsterdam]: amsterdam.ibm.com
Enter the WebSEAL server host name (“amsterdam.ibm.com”).
Enter WebSEAL listening port [7234]:
Press the Enter key to accept the default WebSEAL listening port.
Enter administrator ID [sec_master]:
Press the Enter key to accept the default Access Manager Administrator Id (“sec_master”).
Enter administrator password:passw0rd
Enter the password for “sec_master” (i.e. “passw0rd”).
Enable SSL communication with the LDAP server (y/n) [y]?n
Enter “n” to skip configuration of SSL communication with the LDAP server (as we are setting up a demonstration/test system in this document).
Allow HTTP access (y/n) [y]?
Press the Enter key to allow HTTP access to WebSEAL.
Enter HTTP port [80]:
Press the Enter key to accept the default HTTP port (80).
Allow secure HTTPS access (y/n) [y]?
Press the Enter key to allow HTTPS access to WebSEAL.
Enter HTTPS port [443]:
Press the Enter key to accept the default HTTPS port (443).
Enter Web document root directory [/opt/pdweb/www-default/docs]:
Press the Enter key to accept the default document root location for WebSEAL. The WebSEAL instance will now be configured.
Configuring WebSEAL instance 'default'...
Starting the: webseald-default
The WebSEAL instance 'default' has been successfully configured.
Press <Enter> to continue...
Press the Enter key to return to the WebSEAL Setup menu. Exit the Access Manager Configuration Utility by entering “x” on each of the menus displayed.
2.8.3 Test WebSEAL Configuration
Display the URL http://amsterdam.ibm.com/ in a browser window.
This screen comes from the WebSEAL server, and identifies an expected error. The default security policy for WebSEAL does not allow access by unauthenticated users.
Click the “Re-access the page using HTTPS” link.
This screen appears because the default server certificate that ships with WebSEAL is a self-signed certificate, and is therefore not signed by a recognized Certificate Authority. As we are using a test system, select the “Accept this certificate permanently” radio button and press “OK”.
This screen is displayed by the browser when it receives the X.509 server certificate from WebSEAL, because not only is the default X.509 server certificate that ships with WebSEAL not signed by a certificate Authority that your browser recognizes, but the dummy server name in the certificate also does not match your server name.
For a production system (or possibly even a test system), you will need to obtain a valid server certificate from a recognized Certificate Authority. Refer to the TAM WebSEAL documentation for details on how to replace the default X.509 server certificate with one from a recognized Certificate Authority.
Pres “OK” to accept the certificate.
The default authentication means for WebSEAL is basic authentication. We will later change this to forms-based authentication.
Enter “sec_master” and “passw0rd” the “User Name” and “Password” fields (respectively) and press “OK” to continue.
This is the default home page for the WebSEAL server.
Close all browser windows. It is important that all browser windows are closed here as it is the only way to logout of a system that uses Basic Authentication (due to caching of credentials in the browser).
2.8.4 [Optional] Not Tested Apply Fixpack 2 for Tivoli® Access Manager WebSEAL 5.1
Tivoli® Access Manager 5.1 WebSEAL does not require fixpack 2 for the integration with WPS; however, the fixpack does contain several key fixes that will likely make it worthwhile installing. You must install the Tivoli® Access Manager 5.1 base fixpack 2 prior to installing the WebSEAL fixpack.
Stop Access Manager WebSEAL server as follows (commands are shown in bold):
# pdweb stop
Stopping the: webseald-default
2.8.4.1 Upgrade TAM WebSEAL
Fixpack 2 for TAM 5.1 can be downloaded from the following URL:
http://www3.software.ibm.com/ibmdl/pub/software/tivoli_support/patches/patches_5.1/
The following instructions assume you have downloaded the fixpack installation file for SUSE 8 on X-Series (“5.1-AWS-FP02-LIN.tar”) to “/tmp”.
Unpack and install the fixpack as follows (commands are shown in bold):
# mkdir /tmp/websealfp2
# cd /tmp/websealfp2
# tar xvf /tmp/5.1-AWS-FP02-LIN.tar
PDWeb-PD-5.1.0-2.i386.rpm
PDWebADK-PD-5.1.0-2.i386.rpm
PDWebARS-PD-5.1.0-2.i386.rpm
PDWebRTE-PD-5.1.0-2.i386.rpm
# rpm -Uvh PDWebRTE-PD-5.1.0-2.i386.rpm PDWeb-PD-5.1.0-2.i386.rpm
PDWebRTE-PD ##################################################
PDWeb-PD ##################################################
Verify the versions of TAM installed as follows (commands are shown in bold):
# pdversion
IBM® Tivoli® Access Manager Runtime 5.1.0.2
IBM® Tivoli® Access Manager Policy Server 5.1.0.2
IBM® Tivoli® Access Manager Web Portal Manager 5.1.0.2
IBM® Tivoli® Access Manager Authorization Server 5.1.0.2
IBM® Tivoli® Access Manager Java Runtime Environment 5.1.0.2
IBM® Tivoli® Access Manager Policy Proxy Server 5.1.0.2
IBM® Tivoli® Access Manager WebSEAL Server 5.1.0.2
Confirm that the product level shown for the WebSEAL component is now “5.1.0.2”.
Restart the TAM WebSEAL server as follows (commands are shown in bold):
# pdweb restart
Starting the: webseald-default
You may want to repeat the simple WebSEAL login test we did earlier (after we installed WebSEAL) to confirm that the server started correctly.
2.9 Integrate Authentication
2.9.1 Add MIME Types to WebSphere® Application Server
WebSEAL requires accurate MIME types for files that pass through it. We will now add MIME types for ActiveX Controls and Java Archive files, which are missing from the standard set of MIME types in WebSphere Application Server. These MIME types are required for the Lotus components of WPS Extend.
Ensure the application server “server1” is running.
The following JACL script will add two new MIME types:
· Type: application/x-cabinets-Win32-x86 Extension: cab
· Type: application/java-archive Extension: jar
The script is based on the following assumptions (which should be valid if you are installing a demonstration/test system using the approach outlined in this document):
· Only one cell is defined in the WebSphere® Application Server.
· If one of the new MIME types already exists, then it has exactly the extension shown above.
If you prefer not to use the following script, you could use the WebSphere® Administration Console to add these two MIME types ‑ refer to the WebSphere® Application Server documentation for details on using the WebSphere® Administration Console.
Create a temporary file (“/home/amsterdam/config.mime.types.jacl”) containing the following JACL script ‑ [Note: This file is in the ZIP archive embedded in this document]:
# --------------------------------------------------------------------#
# Add MIME Types needed by WebSEAL
# --------------------------------------------------------------------#
# set constants
set newType1 "application/x-cabinets-Win32-x86"
set newType2 "application/java-archive"
set newTypes [list $newType1 $newType2]
set newExtn1 "cab"
set newExtn2 "jar"
set newExtns [list $newExtn1 $newExtn2]
set virtualHost "default_host"
puts "** Mime Type Configuration Script **"
#
# Get current cell name - abort if more than 1 cell
#
set cells [$AdminConfig list Cell]
if {[llength $cells] > 1} {
puts "### Error - Script Assumption Violated - More than 1 cell found"
$AdminConfig reset
exit -1
}
set cell [lindex [$AdminConfig list Cell] 0]
set cellname [$AdminConfig showAttribute $cell name]
puts "** Cell Name: $cellname"
#
# Find default virtal host
#
set vhosts [$AdminConfig list VirtualHost $cell]
set match 0
foreach vhost $vhosts {
set v [$AdminConfig showAttribute $vhost name]
if {[string compare $v $virtualHost] == 0} {
set match 1
break
}
}
set vhostname [$AdminConfig showAttribute $vhost name]
puts "** Virtual Host: $vhostname"
set mimeEntries [lindex [$AdminConfig showAttribute $vhost mimeTypes] 0]
#
# Process each new MIME entry in turn
#
foreach i [list 0 1] {
set newType [lindex $newTypes $i]
set newExtn [lindex $newExtns $i]
# Check to see if MIME type already exists
puts "** Looking for MIME type: $newType"
set match 0
foreach entry $mimeEntries {
set m [$AdminConfig showAttribute $entry {type}]
if {[string compare $m $newType] == 0} {
set match 1
break
}
}
# If MIME type exists, check extension also exists
if {$match == 1} {
puts "**** Found MIME type: $newType - checking for extension: $newExtn"
set extns [$AdminConfig showAttribute $entry {extensions}]
if {[string compare $extns $newExtn] == 0} {
puts "****** Found Extension: $newExtn"
} else {
puts "### Error - Script Assumption Violated - Extension: $newExtn not found for MIME type: $newType"
$AdminConfig reset
exit -1
}
continue
}
# If MIME type does not exist, add it
puts "**** MIME type: $newType not found"
set entryAttrib {}
lappend entryAttrib [list extensions $newExtn]
lappend entryAttrib [list type $newType]
$AdminConfig create MimeEntry $vhost $entryAttrib
puts "**** MIME type: $newType added with extensions: $newExtn"
}
# Save the Configuration Changes
$AdminConfig save
puts "** Configuration changes successfully saved"
puts "** Script Complete **"
exit 0
Now execute this JACL script as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/wsadmin.sh -f /home/amsterdam/config.mime.types.ja
cl -user wpsbind -password passw0rd >WASX7209I: Connected to process "server1" on node amsterdam using SOAP connector; The type of process is: UnManagedProcess
** Mime Type Configuration Script **
** Cell Name: amsterdam
** Virtual Host: default_host
** Looking for MIME type: application/x-cabinets-Win32-x86
**** MIME type: application/x-cabinets-Win32-x86 not found
**** MIME type: application/x-cabinets-Win32-x86 added with extensions: cab
** Looking for MIME type: application/java-archive
**** MIME type: application/java-archive not found
**** MIME type: application/java-archive added with extensions: jar
** Configuration changes successfully saved
** Script Complete **
Confirm that the script output matches that shown above. If the script aborted due to one of the script assumptions being violated, refer to the WebSphere® Application Server Information Center for instructions on how to add the required MIME types.
Regenerate the WebSphere® Application Server plug-in as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/GenPluginCfg.sh
IBM® WebSphere® Application Server, Release 5.1
WebSphere® Plugin Configuration Generator
Copyright IBM® Corp., 1997-2004
PLGC0013I: Generating server plugin configuration file for all of the servers in cell amsterdam.
PLGC0041W: Unable to load the helper class: com.ibm.wkplc.generator.LotusCfgHelper. No action required if lotus workplace servers are not defined.
PLGC0005I: Plugin Configuration file = /opt/WebSphere/AppServer/config/cells/p
lugin-cfg.xml2.9.2 Configure Junctions from WebSEAL to the IBM® HTTP Server
In this section we will configure two web connectors (termed “junctions”) from the WebSEAL reverse proxy server to the IBM® HTTP Server ‑ one junction will be HTTP and the other will be HTTPS.
The approach used in this document is to have all public portal content pass over HTTP and private portal content pass over HTTPS ‑ this is done for traffic between both the browser and WebSEAL, and WebSEAL and the IBM® HTTP Server.
2.9.2.1 Load the IBM® HTTP Server CA certificate into WebSEAL Keystore
As we used a self-signed certificate as the server certificate for the IBM® HTTP Server, we need to load the associated CA certificate into the keystore used by WebSEAL for SSL junctions.
Start the IBM® Key Management Utility as follows (commands are in bold):
# . /opt/WebSphere/AppServer/bin/setupCmdLine.sh
# gsk7ikm
Select “Key Database File -> Open” from the menu bar.
Change the path name to “/opt/pdweb/www-default/certs/” and enter “pdsrv.kdb” in the file name field ‑ this is the keystore used by WebSEAL to store acceptable CA certificates for SSL junctions. Press the “Open” button to open the keystore.
Enter the default password for the WebSEAL keystore, “pdsrv”, and press “OK” to continue.
Select “Signer Certificates” from the pull-down menu.
Press the “Add” button.
Enter the following field values and press “OK” to continue:
· Data type Base64-encoded ASCII data
· Certificate file name ihs.arm
· Location /opt/IBMHttpServer/keytab
Enter “IHS" as the label for the new certificate and press “OK” to continue.
Exit the IBM® Key Management utility.
Stop and restart the Access manager WebSEAL server, as follows (commands are shown in bold):
# pdweb restart
Stopping the: webseald-default
Starting the: webseald-default
2.9.2.2 Configure “query_contents” CGI for the IBM® HTTP Server
In order to provide directory listings and ACL drag-and-drop capabilities in the Access Manager Web Portal Manager (WPM) GUI for the static content hosted in the IBM® HTTP Server, we will install and configure a simple CGI script in the IBM® HTTP Server CGI directory. This script provides a remote directory listing function for use by WPM.
Copy:
/opt/pdweb/html.tivoli/query_contents/query_contents.sh
to
/opt/IBMHttpServer/cgi-bin/query_contentsChange the owner name and group of the new file, as follows (commands are shown in bold):
# cp /opt/pdweb/html.tivoli/query_contents/query_contents.sh /opt/IBMHttpServe
r/cgi-bin/query_contents# chown nobody:nobody /opt/IBMHttpServer/cgi-bin/query_contents
Modify the values shown below in bold in the file:
“/opt/IBMHttpServer/cgi-bin/query_contents”:
case "$SERVER_SOFTWARE" in
WebSEAL*|WAND*)
DOCROOTDIR=`pwd`
;;
Apache*)
DOCROOTDIR=`pwd`/../htdocs
ADD_TO_ROOT="cgi-bin//"
;;
CERN*)
DOCROOTDIR=/home/www/Web
ADD_TO_ROOT="cgi-bin//"
;;
IBM_HTTP_SERVER*)
DOCROOTDIR=`pwd`/../htdocs/en_US
ADD_TO_ROOT="cgi-bin//"
;;
*)
DOCROOTDIR=/usr/local/html
esac
…
case "$SERVER_SOFTWARE" in
CERN*|Apache*)
case "$OBJPATH" in
cgi-bin|cgi-bin/*)
TMPOBJPATH=`echo $OBJPATH | sed -e "s;^cgi-bin;;" -e "s;^/;;"`
FULLOBJPATH=$DOCROOTDIR/../cgi-bin/$TMPOBJPATH
;;
esac
;;
IBM_HTTP_SERVER*)
case "$OBJPATH" in
cgi-bin|cgi-bin/*)
TMPOBJPATH=`echo $OBJPATH | sed -e "s;^cgi-bin;;" -e "s;^/;;"`
FULLOBJPATH=$DOCROOTDIR/../../cgi-bin/$TMPOBJPATH
;;
esac
;;
esac
…
[Note: A modified copy of this file is in the ZIP archive embedded in this document]
2.9.2.3 Define WebSEAL Junctions to the IBM® HTTP Server
Create a temporary file (“/home/amsterdam/define.junctions.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
server task default-webseald-amsterdam.ibm.com create -t tcp -h w502t
51s8.ibm.com -p 81 -j -w -i –q /cgi-bin/query_contents.exe /wasserver task default-webseald-amsterdam.ibm.com create -t ssl -h w502t
51s8.ibm.com -p 444 -j -w -i -c iv-user,iv-creds –b supply –q /cgi-bi
n/query_contents.exe /wass(Note: type each “server task” command on a single line and let the shell window wrap as needed)
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/define.junctions.pd
Enter Password:passw0rd
cmd> server task default-webseald-amsterdam.ibm.com create -t tcp -h amsterdam.ibm.com -p 81 -f -j -q /cgi-bin/query_contents /was
Created junction at /was
cmd> server task default-webseald-amsterdam.ibm.com create -t ssl -h amsterdam.ibm.com -p 444 -f -j -c iv-user,iv-creds -b supply -q /cgi-bin/query_contents /wass
Created junction at /wass
cmd>
2.9.3 Configure WebSEAL for URL Filtering & Forms-Based Authentication
2.9.3.1 Modify “webseald.conf”
In order to configure WebSEAL to rewrite the absolute URLs produced by WebSphere® Portal Server we need to perform a minor configuration change in the primary WebSEAL configuration file. We will also configure WebSEAL to use forms-based authentication and set several other timeouts/parameters.
Create a temporary file (“/home/amsterdam/update.webseald.ksh”) containing the following commands:
[Note: This file is in the ZIP archive embedded in this document]:#!/bin/ksh
cd /opt/pdweb/etc
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry server dynurl-allow-large-posts yes
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry junction http-timeout 300
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry junction https-timeout 300
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry junction basicauth-dummy-passwd passw0rd
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry script-filtering script-filter yes
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry ba ba-auth none
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry forms forms-auth https
/opt/PolicyDirector/sbin/pdconf -f webseald-default.conf setentry session ssl-id-sessions no
(Note: type each command on a single line and let the shell window wrap as needed)
Note that if you plan on using a different password for the userid that we will use for the Trust Association Interceptor (“was_tai”), edit the above script and replace the value for the “basicauth-dummy-passwd” parameter from “passw0rd” to your preferred password value.
Now execute the script file, as follows (commands are shown in bold):
# chmod 700 /home/amsterdam/update.webseald.ksh
# /home/amsterdam/update.webseald.ksh
2.9.4 Define a Junction Management Table for WebSEAL
Create a file “jmt.conf” in “/opt/pdweb/www-default/lib” containing the following lines ‑ [Note: This file is in the ZIP archive embedded in this document]:
/was /wps/portal*
/was /wps/config*
/was /wps/doc*
/wass /wps/myportal*
/wass /snoop*
These JMT entries will allow a user to type a URL accessing WPS without including the junction name.
Ensure the owner id and group for the “jmt.conf” are both set to “ivmgr” , as follows (commands are shown in bold).
# chown ivmgr:ivmgr /opt/pdweb/www-default/lib/jmt.conf
2.9.5 Create Access Manager Objects for the WebSphere® Portal Servlets
Create a file “dynurl.conf” in “/opt/pdweb/www-default/lib” containing the following lines ‑ [Note: This file is in the ZIP archive embedded in this document]:
/was/wps/portal /was/wps/portal*
/was/wps/myportal /was/wps/myportal*
/was/wps/config /was/wps/config*
/was/wps/doc /was/wps/doc*
/was/snoop /was/snoop*
/wass/wps/portal /wass/wps/portal*
/wass/wps/myportal /wass/wps/myportal*
/wass/wps/config /wass/wps/config*
/wass/snoop /wass/snoop*
/was /wps*
/was /snoop*
Note that we have added entries for both the “before” and “after” versions of URLs that will be handled by the JMT. This is necessary as WebSEAL will perform two ACL checks, one on the URL before the JMT transformation and one after; both must pass for access to be granted. Given that the real access control check is the second one, we have added dummy entries for the “before” versions and mapped them to an object that is readable by both unauthenticated and authenticated users (“/was”) ‑ so the first ACL check will now always pass.
Ensure the owner id and group for the “dynurl.conf” are both set to “ivmgr”.
# chown ivmgr:ivmgr /opt/pdweb/www-default/lib/dynurl.conf
Stop and restart the Access manager WebSEAL server, as follows (commands are shown in bold):
# pdweb restart
Stopping thez`: webseald-default
Starting the: webseald-default
2.9.6 Define Access Control Policy for the “query_contents” Program
Create a temporary file (“/home/amsterdam/set.query_contents.policy.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
acl create WPS_query_contents
acl modify WPS_query_contents set user sec_master dbxTrlcam
acl modify WPS_query_contents set group ivmgrd-servers Tl
acl attach /WebSEAL/amsterdam.ibm.com-default/was/cgi-bin/query_conten
ts WPS_query_contentsacl attach /WebSEAL/amsterdam.ibm.com-default/wass/cgi-bin/query_conte
nts WPS_query_contents(Note: type each command on a single line and let the shell window wrap as needed)
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/set.query_contents.policy.pd
Enter Password:passw0rd
cmd> acl create WPS_query_contents
cmd> acl modify WPS_query_contents set user sec_master dbxTrlcam
cmd> acl modify WPS_query_contents set group ivmgrd-servers Tl
cmd> acl attach /WebSEAL/amsterdam.ibm.com-default/was/cgi-
bin/query_contents WPS_query_contentscmd> acl attach /WebSEAL/amsterdam.ibm.com-default/wass/cgi-bin/query
_contents WPS_query_contentscmd>
2.9.7 Import WPS Users and Groups into Access Manager
We will now import the existing WebSphere® Portal Server users and groups into Access Manager ‑ this will add the auxiliary LDAP class information required by Access Manager.
Create a temporary file (“/home/amsterdam/import.wps.users.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
user import –gsouser wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com
user modify wpsadmin account-valid yes
user modify wpsadmin password-valid yes
group import wpsadmins cn=wpsadmins,cn=groups,dc=ibm,dc=com
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/import.wps.users.pd
Enter Password:passw0rd
cmd> user import -gsouser wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com
cmd> user modify wpsadmin account-valid yes
cmd> user modify wpsadmin password-valid yes
cmd> group import wpsadmins cn=wpsadmins,cn=groups,dc=ibm,dc=com
2.9.8 Create TAM Access Control Lists for Use With WPS
We will now create several Access Control Lists in Access Manager for use in defining the web policy needed for the WebSphere® Portal application. If you perform the optional section later in this document relating to configuring WebSphere® Portal for external authorization, we will update these ACLs to add permissions relevant to WPS resources.
Create a temporary file (“/home/amsterdam/create.wps.acls.pd”) containing the following “pdadmin” commands:
[Note: This file is in the ZIP archive embedded in this document]:acl create WPS_Admins_only
acl create WPS_No_access
acl create WPS_Authenticated_access
acl create WPS_All_access
acl modify WPS_Admins_only set user sec_master TcmdbsvaBRrxl
acl modify WPS_Admins_only set group iv-admin TcmdbsvaBRrxl
acl modify WPS_Admins_only set group webseal-servers Tgmdbsrxl
acl modify WPS_Admins_only set group wpsadmins Tr
acl modify WPS_Admins_only set any-other T
acl modify WPS_Admins_only set unauthenticated T
acl modify WPS_No_access set user sec_master TcmdbsvaBRrxl
acl modify WPS_No_access set group iv-admin TcmdbsvaBRrxl
acl modify WPS_No_access set group webseal-servers Tgmdbsrxl
acl modify WPS_No_access set group wpsadmins T
acl modify WPS_No_access set any-other T
acl modify WPS_No_access set unauthenticated T
acl modify WPS_Authenticated_access set user sec_master TcmdbsvaBRrxl
acl modify WPS_Authenticated_access set group iv-admin TcmdbsvaBRrxl
acl modify WPS_Authenticated_access set group webseal-servers Tgmdbsrxl
acl modify WPS_Authenticated_access set group wpsadmins Tr
acl modify WPS_Authenticated_access set any-other Tr
acl modify WPS_Authenticated_access set unauthenticated T
acl modify WPS_All_access set user sec_master TcmdbsvaBRrxl
acl modify WPS_All_access set group iv-admin TcmdbsvaBRrxl
acl modify WPS_All_access set group webseal-servers Tgmdbsrxl
acl modify WPS_All_access set group wpsadmins Tr
acl modify WPS_All_access set any-other Tr
acl modify WPS_All_access set unauthenticated Tr
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/create.wps.acls.pd
Enter Password:passw0rd
cmd> acl create WPS_Admins_only
cmd> acl create WPS_No_access
cmd> acl create WPS_Authenticated_access
cmd> acl create WPS_All_access
cmd> acl modify WPS_Admins_only set user sec_master TcmdbsvaBRrxl
cmd> acl modify WPS_Admins_only set group iv-admin TcmdbsvaBRrxl
cmd> acl modify WPS_Admins_only set group webseal-servers Tgmdbsrxl
cmd> acl modify WPS_Admins_only set group wpsadmins Tr
cmd> acl modify WPS_Admins_only set any-other T
cmd> acl modify WPS_Admins_only set unauthenticated T
cmd> acl modify WPS_No_access set user sec_master TcmdbsvaBRrxl
cmd> acl modify WPS_No_access set group iv-admin TcmdbsvaBRrxl
cmd> acl modify WPS_No_access set group webseal-servers Tgmdbsrxl
cmd> acl modify WPS_No_access set group wpsadmins T
cmd> acl modify WPS_No_access set any-other T
cmd> acl modify WPS_No_access set unauthenticated T
cmd> acl modify WPS_Authenticated_access set user sec_master TcmdbsvaBRrxl
cmd> acl modify WPS_Authenticated_access set group iv-admin TcmdbsvaBRrxl
cmd> acl modify WPS_Authenticated_access set group webseal-servers Tgmdbsrxl
cmd> acl modify WPS_Authenticated_access set group wpsadmins Tr
cmd> acl modify WPS_Authenticated_access set any-other Tr
cmd> acl modify WPS_Authenticated_access set unauthenticated T
cmd> acl modify WPS_All_access set user sec_master TcmdbsvaBRrxl
cmd> acl modify WPS_All_access set group iv-admin TcmdbsvaBRrxl
cmd> acl modify WPS_All_access set group webseal-servers Tgmdbsrxl
cmd> acl modify WPS_All_access set group wpsadmins Tr
cmd> acl modify WPS_All_access set any-other Tr
cmd> acl modify WPS_All_access set unauthenticated Tr
cmd>
2.9.8.1 Create POP for WebSphere® Portal Server
We will define an Access Manager Protected Object Policy (POP) that we will later attach to the “/wps/myportal” URL object to ensure that the portal private pages are always accessed over HTTPS (and not HTTP). WebSphere® Portal should also enforce this, so in effect we are using the POP as more of a programming language style “assertion” here.
Create a temporary file (“/home/amsterdam/create.wps.pop.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
pop create SSL_only
pop modify SSL_only set qop privacy
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/create.wps.pop.pd
Enter Password:passw0rd
cmd> pop create SSL_only
cmd> pop modify SSL_only set qop privacy
cmd>
2.9.8.2 Attach ACLs and POP to Objects for WebSphere® Portal Server
Now that we have created the required ACLs and POP, we will attach them to the appropriate URL objects in Access Manager.
Create a temporary file (“/home/amsterdam/attach.web.acls.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
acl attach /WebSEAL/amsterdam.ibm.com-default/was WPS_All_access
acl attach /WebSEAL/amsterdam.ibm.com-default/was/wps/config WPS_Admin
s_onlyacl attach /WebSEAL/amsterdam.ibm.com-default/was/wps/myportal WPS_No_
accessacl attach /WebSEAL/amsterdam.ibm.com-default/was/snoop WPS_No_access
acl attach /WebSEAL/amsterdam.ibm.com-default/wass WPS_All_access
acl attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/config WPS_Admi
ns_onlyacl attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/myportal WPS_Au
thenticated_accesspop attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/myportal SSL_on
lyacl attach /WebSEAL/amsterdam.ibm.com-default/wass/snoop WPS_Authentic
ated_access(Note: type each command on a single line and let the shell window wrap as needed)
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master attach.web.acls.pd
Enter Password:passw0rd
cmd> acl attach /WebSEAL/amsterdam.ibm.com-default/was WPS_All_access
cmd> acl attach /WebSEAL/amsterdam.ibm.com-default/was/wps/config WPS
_Admins_onlycmd> acl attach /WebSEAL/amsterdam.ibm.com-default/was/wps/myportal W
PS_No_accesscmd> acl attach /WebSEAL/amsterdam.ibm.com-default/was/snoop WPS_No_a
ccesscmd> acl attach /WebSEAL/amsterdam.ibm.com-default/wass WPS_All_acces
scmd> acl attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/config WP
S_Admins_onlycmd> acl attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/myportal WPS_Authenticated_access
cmd> pop attach /WebSEAL/amsterdam.ibm.com-default/wass/wps/myportal SSL_only
cmd> acl attach /WebSEAL/amsterdam.ibm.com-default/wass/snoop WPS_Aut
henticated_accesscmd>
2.9.9 Modify WPS Login/Logout Functions to work with WebSEAL
2.9.9.1 [Optional] Enable automatic JSP Reloading
This steps allows you to make modifications to the JSP files for WPS without having to restart the server to test each change. This is a step for development purposes and would not be configured in a production environment.
Follow these steps to enable automatic JSP reloading:
- Open the file was_root/config/cells/node_name/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ ibm-web-ext.xmi
- Find the following entry in this file:
3. <webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
4. xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi"
5. xmlns:commonext="commonext.xmi" xmlns:common="common.xmi"
6. xmi:id="IBM_WPS_Ext" reloadInterval="3" reloadingEnabled="false"
7. fileServingEnabled="true" directoryBrowsingEnabled="false"
8. serveServletsByClassnameEnabled="false" preCompileJSPs="false">
- Change the value for reloadingEnabled to true.
- Save the file.
- Restart the portal server.
After completing these steps, JSPs are automatically reloaded when they are changed. However, to view changes to a JSP that is included by another (parent) JSP, you must also change the parent JSP to indicate that it must be reloaded by the server
2.9.9.2 Update ToolBarInclude.jsp files for all themes.
By default, when unauthenticated users attempt to access the myportal page, they get redirected to the login screen located at wps/portal/.scr/Login to provide a user name and password. When using a WebSEAL for authentication, you no longer need to use the WebSphere® Portal login screen. Instead, the login icon should point to the myportal page.
The steps to update the login process are as follows:
- Use this address to test the TAI from a Web browser:
- https://WebSEAL_hostname/junction/wps/myportal
WebSEAL or SiteMinder should challenge you to authenticate. After you log in, you should be directed to the secure and personalized myportal page. If you are directed to the portal login screen at wps/portal/.scr/Login or the public page, there is a problem with the TAI configuration.
- Make backup copies of the was_root/installedApps/node_name/wps.ear/wps.war/themes/html/ theme_name/ToolBarInclude.jsp files in the appropriate themes subdirectories. Edit the login button section in each file as shown in bold here. The hardcoded URL is required as the public portal page is over HTTP and myportal is protected and must be accessed over HTTPS:
<%-- login button --%>
<wps:if loggedIn="no" notScreen="Login">
<td"wpsToolBar" valign="middle" align="<%=bidiAlignRight%>" nowrap>
<a"wpsToolBarLink" href=https://amsterdam.ibm.com/wass/wps/myportal> <wps:text key="link.login" bundle="nls.engine"/></a>
</td>
</wps:if>.
- Make a backup copy of the was_root/installedApps/node_name/wps.ear/wps.war/WEB-INF/web.xml file. Edit the file as shown in bold here:
<login-config id="LoginConfig_1">
<auth-method>FORM</auth-method>
<realm-name>WPS</realm-name>
<form-login-config id="FormLoginConfig_1">
<form-login-page>/myportal</form-login-page>
<form-error-page/error.html/form-error-page>
</form-login-config>
</login-config> - Restart WebSphere® Portal.
2.9.9.3 Replace “ErrorSessionTimeout.jsp”
Edit the file:
/opt/WebSphere/AppServer/installedApps/amsterdam/wps.ear/wps.war/screens/html/ErrorSessionTimeout.jsp
and replace its contents with the following -- [Note: A modified version of this file is in the ZIP archive embedded in this document]:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Refresh" content="2;URL=https://amsterdam.ibm.com/wass/wps/myportal">
</head>
<body>
<BR><BR>
Refreshing WebSphere® Portal user credentials after session timeout ... select <a href="https://amsterdam.ibm.com/wass/wps/myportal">here</a> if your browser does not automatically redirect within 2 seconds.
</body>
</html>
(Note: In the “<html>” section, with the exception of the line beginning with “Redirecting”, any lines not beginning with “<” are continuations of the preceding line and should be entered as such).
2.9.9.4 Edit “ConfigService.properties”
Edit the file:
/opt/WebSphere/PortalServer/shared/app/config/services/ConfigService.properties
and modify the entries shown in bold below:
...
# Logout redirect parameters
#
# Default: false, false, <none>
redirect.logout = true
redirect.logout.ssl = true
redirect.logout.url = https://amsterdam.ibm.com/pkmslogout?filename=wpslogout.html
…
(Note: the value for “redirect.logout.url” should appear on one line).
2.9.9.5 Create “wpslogout.html”
Create the file:
/opt/pdweb/www-default/lib/html/C/wpslogout.html
with the following contents ‑ [Note: This file is in the ZIP archive embedded in this document]:
<script language=javascript type="text/javascript">
<!--
// Set this variable to a semi-colon list of the names of cookies
// you do not want to delete
var exception_list = "";
function delete_cookie (name, path)
{
// Set expiration date to last year
var expiration_date = new Date ();
expiration_date . setYear (expiration_date . getYear () - 1);
expiration_date = expiration_date . toGMTString ();
// Expire the cookie
var cookie_string = name + "=; expires=" + expiration_date;
if (path != null)
cookie_string += "; path=" + path;
document . cookie = cookie_string;
}
function name_in_list (n, lst)
{
var arr = lst . split ("; ");
for (var j = 0; j < arr . length; j ++) {
if (arr[j] == n)
return true;
}
return false;
}
function delete_all_cookies (path, exceptions)
{
// Get cookie list and split into an array of cookie entries
var cookie_string = "" + document . cookie;
var cookie_array = cookie_string . split ("; ");
// Delete each cookie ...
// EXCEPT those whose names appear in the semicolon delimited list
// passed in as the second parameter to this function
for (var i = 0; i < cookie_array . length; ++ i) {
var single_cookie = cookie_array [i] . split ("=");
var name = single_cookie [0];
if (name_in_list(name, exceptions) == false)
delete_cookie (name, path);
}
}
// -->
</script>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="Refresh" content="2;URL=http://amsterdam.ibm.com/was/wps/portal">
<title>PKMS Administration: User Log Out</title>
</head>
<body bgcolor="#FFFFFF" text="#000000" onLoad=delete_all_cookies("/",exception_list)>
<font size="+2"><b>User %USERNAME% has logged out.</b></font>
<BR><BR>
<BR><BR>
Redirecting to public portal page ... select <a href="http://amsterdam.ibm.com/was/wps/portal">here</a> if your browser does not automatically redirect after 2 seconds.
</body>
</html>
(Note: In the “<html>” section, with the exception of the line beginning with “Redirecting”, any lines not beginning with “<” are continuations of the preceding line and should be entered as such).
Update the file ownership and file permissions on the new file as follows (commands are shown in bold):
# chown ivmgr:ivmgr /opt/pdweb/www-default/lib/html/C/wpslogout.html
# chmod 440 /opt/pdweb/www-default/lib/html/C/wpslogout.html
2.9.9.6 Modify “logout.html”
Edit the file:
/opt/pdweb/www-default/lib/html/C/logout.html
and modify the entries shown in bold below ‑ [Note: This file is in the ZIP archive embedded in this document]:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!-- Copyright (C) 2000 Tivoli® Systems, Inc. -->
<!-- Copyright (C) 1999 IBM® Corporation -->
<!-- Copyright (C) 1998 Dascom, Inc. -->
<!-- All Rights Reserved. -->
<script language=javascript type="text/javascript">
<!--
// Set this variable to a semi-colon list of the names of cookies
// you do not want to delete
var exception_list = "";
function delete_cookie (name, path)
{
// Set expiration date to last year
var expiration_date = new Date ();
expiration_date . setYear (expiration_date . getYear () - 1);
expiration_date = expiration_date . toGMTString ();
// Expire the cookie
var cookie_string = name + "=; expires=" + expiration_date;
if (path != null)
cookie_string += "; path=" + path;
document . cookie = cookie_string;
}
function name_in_list (n, lst)
{
var arr = lst . split ("; ");
for (var j = 0; j < arr . length; j ++) {
if (arr[j] == n)
return true;
}
return false;
}
function delete_all_cookies (path, exceptions)
{
// Get cookie list and split into an array of cookie entries
var cookie_string = "" + document . cookie;
var cookie_array = cookie_string . split ("; ");
// Delete each cookie ...
// EXCEPT those whose naems appear in the semicolon delimited list
// passed in as the second parameter to this function
for (var i = 0; i < cookie_array . length; ++ i) {
var single_cookie = cookie_array [i] . split ("=");
var name = single_cookie [0];
if (name_in_list(name, exceptions) == false)
delete_cookie (name, path);
}
}
// -->
</script>
<html>
<head>
<meta http-equiv="Content-Type" content=
"text/html; charset=iso-8859-1">
<title>PKMS Administration: User Log Out</title>
</head>
<body bgcolor="#FFFFFF" text="#000000" onLoad=delete_all_cookies("/",exception_list)>
<font size="+2"><b>User %USERNAME% has logged out.</b></font>
</body>
</html>
(Note: In the “<html>” section, any lines not beginning with “<” are continuations of the preceding line and should be entered as such).
2.9.10 Configure SSO from WebSEAL to WebSphere® Application Server
The approach taken in this document for single sign-on from WebSEAL to WebSphere® Application Server is to use a Trust Association Interceptor. An equally valid approach is to use LTPA junctions from WebSEAL to WebSphere® Application Server. If you prefer to use LTPA junctions, refer to the TAM documentation for details on how to configure them.
2.9.10.1 Create Dummy User for Trust Association Interceptor
We will now create a dummy userid for use by the Trust Association Interceptor. This dummy userid, in conjunction with the dummy password inserted in the HTTP header by WebSEAL, will allow the TAI to perform some level of verification that the request came from WebSEAL. The TAI will check to see if the password sent by WebSEAL is indeed the password for the dummy userid that is specified in the “webseald.conf” file. If the dummy values are not a valid userid-password combination, the TAI will not authenticate the user to the WebSphere® Application Server.
For a production system, a more secure approach would be to use a mutually authenticated junction (using X.509 certificates) between WebSEAL and the IBM® HTTP Server. Similarly the connection between the IBM® HTTP Server and the WebSphere® Application Server should also be configured as a mutually authenticated HTTPS connection in a production system.
Note that since we are using the WPS defaults for the LDAP object classes in this document, we cannot use “pdadmin” or WPM to create the user. We could create the user in WPS, but we will create the user via LDIF here.
Create a temporary file (“/home/amsterdam/was_tai.ldif”) containing the following ‑ [Note: This file is in the ZIP archive embedded in this document]:
dn: uid=was_tai,cn=users,dc=ibm,dc=com
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: was_tai
userpassword: passw0rd
sn: User
givenName: Dummy
cn: Dummy User
Import this LDIF file into the IBM® Directory Server as follows (commands are shown in bold):
# ldapadd –D cn=root –w passw0rd –c –f /home/amsterdam/was_tai.ldif
adding new entry uid=was_tai,cn=users,dc=ibm,dc=com
Create a temporary file (“/home/amsterdam/import.was_tai.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
user import was_tai uid=was_tai,cn=users,dc=ibm,dc=com
user modify was_tai account-valid yes
user modify was_tai password-valid yes
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/import.was_tai.pd
Enter Password:passw0rd
cmd> user import was_tai uid=was_tai,cn=users,dc=ibm,dc=com
cmd> user modify was_tai account-valid yes
cmd> user modify was_tai password-valid yes
cmd>
2.9.10.2 Configure Trust Association Interceptor in WebSphere
Ensure the application server “server1” is running.
We will now use a JACL script to configure the Trust Association Interceptor in WebSphere® Application Server. If you prefer not to use the JACL script, you could use the WebSphere® Administration Console to configure the Trust Association Interceptor ‑ refer to the WebSphere Application Server documentation for details on using the WebSphere Administration Console.
Create a temporary file (“/home/amsterdam/config.was.tai.jacl”) containing the following JACL script ‑ [Note: This file is in the ZIP archive embedded in this document]:
# --------------------------------------------------------------------#
# Set parameters
# (Modify these to suit your environment)
# --------------------------------------------------------------------#
set enable "true"
set type "webseal"
set id "iv-user"
set hosts "amsterdam.ibm.com, amsterdam"
set ports "443"
set loginId "was_tai"
set ignoreProxy "true"
set mutualSSL "false"
# --------------------------------------------------------------------#
# Configure the TAI according to the above parameters
# --------------------------------------------------------------------#
puts "** TAI Configuration Script **"
# Set Interceptor name
set classNameWebseal ”com.ibm.ws.security.web.WebSealTrustAssociationInt
erceptor"# Set Property names
set typeProp com.ibm.websphere.security.trustassociation.types
set loginIdProp com.ibm.websphere.security.webseal.loginId
set hostsProp com.ibm.websphere.security.webseal.hostnames
set portsProp com.ibm.websphere.security.webseal.ports
set idProp com.ibm.websphere.security.webseal.id
set ignoreProxyProp com.ibm.websphere.security.webseal.ignoreProxy
set mutualSSLProp com.ibm.websphere.security.webseal.mutualSSL
# Obtain handle for TAI
set taiId [$AdminConfig list TrustAssociation]
#
# Enable TAI
#
puts "** Set TAI enabled flag to '$enable' **"
set enableAttrib {}
lappend enableAttrib [list enabled "$enable"]
$AdminConfig modify $taiId $enableAttrib
#
# If TAI just enabled, set interceptor properties
#
if {[string compare $enable "true"] == 0} {
# Locate Webseal interceptor (we assume it is already there)
set match 0
set listTAI [$AdminConfig list TAInterceptor]
foreach tai $listTAI {
set className [$AdminConfig showAttribute $tai interceptorClassName]
if {[string compare $className $classNameWebseal] == 0} {
set match 1
break
}
}
if {$match != 1} {
puts "### ERROR - Webseal Interceptor Not Found - Violates Assumption"
exit 1
}
# Construct the property lists
set typeList [list [list name $typeProp] [list value $type]]
set hostsList [list [list name $hostsProp] [list value $hosts]]
set portsList [list [list name $portsProp] [list value $ports]]
set idList [list [list name $idProp] [list value $id]]
set loginIdList [list [list name $loginIdProp] [list value $loginId]]
set ignoreProxyList [list [list name $ignoreProxyProp] [list value $ignoreP
roxy]]set mutualSSLList [list [list name $mutualSSLProp] [list value $mutualSSL]]
# Set up the parameter list
set propList [list $typeList $hostsList $portsList $idList $loginIdList $ign
oreProxyList $mutualSSLList]set trustProps [list [list trustProperties $propList]]
# Add the property settings to the interceptor
puts "** Set TAI properties for the interceptor: $classNameWebseal"
$AdminConfig modify $tai $trustProps
}
# Save the Configuration Changes
$AdminConfig save
puts "** Configuration changes successfully saved"
puts "** Script Complete **"
Note that the parameters in the first block of definitions may need to be modified to fit your environment if you are not following this guide exactly.
Also note that we have set the “ignoreProxy” property to true. This setting causes the TAI to not check the specified hostname and port for WebSEAL on requests (which are passed in the “via” HTTP header). This is only appropriate for a demo/test system and should not be set in a production system.
Now execute the JACL script as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/wsadmin.sh -f /home/amsterdam/config.was.tai.jacl -user wpsbind -password passw0rd
WASX7209I: Connected to process "server1" on node amsterdam using SOAP connec
tor; The type of process is: UnManagedProcess** TAI Configuration Script **
** Set TAI enabled flag to 'true' **
** Set TAI properties for the interceptor: com.ibm.ws.security.web.WebSealTru
stAssociationInterceptor** Configuration changes successfully saved
** Script Complete **
Confirm that the script output matches that shown above.
Stop and restart the application server “server1”, as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh server1 -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/stopServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 7137
Search in “/opt/WebSphere/AppServer/logs/server1/SystemOut.log” for messages of the form:
[3/30/04 20:56:50:025 MST] 2779f1d5 TrustAssociat A SECJ0121I: Trust Association Init class com.ibm.ws.security.web.WebSealTrustAssociationInterceptor loaded successfully
[3/30/04 20:56:50:026 MST] 2779f1d5 TrustAssociat A SECJ0122I: Trust Association Init Interceptor signature: WebSeal Interceptor Version 1.1
Stop and restart the WebSphere Portal Server as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 1900
2.9.10.3 Test the SSO Configuration
Test SSO to the Snoop Servlet
Ensure the application server “server1” is running.
Display the URL https://amsterdam.ibm.com/wass/snoop” in a browser window.
As we have defined the Snoop Servlet as not being accessible from an unauthenticated session, WebSEAL will prompt the user for authentication information.
Enter “wpsadmin” in the “Username” field, and “passw0rd” in the “Password” field. Press “Login” to authenticate the user to WebSEAL and display the requested page.
Scroll down to the “User Principal” entry. It should have the value “wpsadmin”.
Note the entry “via” shown in the above screen image. This HTTP header contains the exact hostname and port values that are checked by the TAI to confirm that the request came from WebSEAL. Also note that the TAI treats the hostname values as case-sensitive.
Enter https://amsterdam.ibm.com/pkmslogout in the URL line of the browser window to logout of WebSEAL.
Perform the same test without including the junction name in the URL:
https://amsterdam.ibm.com/snoop.Note that in this case (with the junction name omitted from the initial URL), the JMT will cause WebSEAL to insert the missing “/wass” junction name into the URL.
Test SSO to the WebSphere® Portal Server
Ensure the WebSphere® Portal application server is running.
Display the URL “http://amsterdam.ibm.com/was/wps/portal” in a browser window.
Click the “Log in” link in the top right corner of the portal page to log in to WebSphere® Portal.
You should then briefly see the following screen:
If you are not redirected to the Access Manager login page within a few seconds, click the “here” link.
Enter “wpsadmin” and “passw0rd” in the appropriate fields and press the “Login” button.
Note that user “wpsadmin” is now authenticated to the WebSphere® Portal Server (via the Trust Association Interceptor).
You can confirm that “wpsadmin” is indeed the current user by selecting the “Edit my profile” link at the top of the screen.
Press the “Cancel” button to return to the main portal page.
Click the “Log out” link (in the top right-hand corner of the portal page).
You should then briefly see the following page:
If this page does not redirect to the WebSphere® Portal public page within a few seconds, click the “here” link. The WPS public page should then be displayed.
Perform the same tests without including the junction name in the URL:
http://amsterdam.ibm.com/wps/portal.Note that in this case the JMT should cause WebSEAL to insert the missing “/was” junction name into the URL. Remember to logout out of WebSEAL after the test.
2.10 Not Tested Integrate JAAS Authentication (Optional)
In this step we will configure WebSphere® Portal Server to extract (and cache) the Access Manager JAAS credential from the HTTP header data sent by WebSEAL. This is an optional, but recommended, step in the integration.
This step is required if you intend to call the Access Manager Authorization API from within a portlet, or if you intend to perform the steps in section 2.11, “Integrate Authorization (Optional)” on page 202.
2.10.1 Configure Access Manager Java Runtime for WPS
Create a temporary file (“/home/amsterdam/svrsslcfg.WPS.ksh”) containing the following commands:
[Note: This file is in the ZIP archive embedded in this document]:#!/bin/ksh
/opt/WebSphere/AppServer/java/jre/bin/java com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id sec_master -admin_pwd passw0rd -appsvr_id amsterdam_amwps -mode remote -port 72
01 -policysvr amsterdam.ibm.com:7135:1 -authzsvr amsterdam.ibm.com:7136:
1 -cfg_file /opt/WebSphere/AppServer/java/jre/PdPerm.properties -key_file /opt/WebSphere
/AppServer/java/jre/lib/security/pdperm.ks -cfg_action create(Note: type each command on a single line and let the shell window wrap as needed)
Now execute the script file, as follows (commands are shown in bold):
# chmod 700 /home/amsterdam/svrsslcfg.WPS.ksh
# /home/amsterdam/update.webseald.ksh
The configuration completed successfully.
2.10.2 Modify WPS Properties Files
2.10.2.1 Modify “ConfigService.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/shared/app/config/services/ConfigService.properties…
execute.portal.jaas.login = true
…
2.10.2.2 Modify “ExternalAccessControlService.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/shared/app/config/services/ExternalAccessControlService.properties…
externalaccesscontrol.pdurl=file:/opt/WebSphere/AppServer/java/jre/PdPerm.properties
…
2.10.2.3 Modify “callbackheaderslist.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServe/sharedapp/config/callbackheaderslist.properties…
# --------------------------------------------------- #
# WebSealLoginModule required headers example:
#
header.1=iv-user
header.2=iv-creds
…
2.10.3 Configure JAAS Authentication in WebSphere® Application Server
Ensure the application server “server1” is running.
The following script configures the required JAAS Authentication modules for WebSphere® Portal. If you prefer not to use the following script, you could use the WebSphere Administration Console to create the required entries ‑ refer to the documentation for WebSphere® Application Server for details on using the WebSphere® Administration Console.
Create a temporary file (“/home/amsterdam/config.was.jaas.jacl”) containing the following JACL script ‑ [Note: This file is in the ZIP archive embedded in this document]:
# --------------------------------------------------------------------#
# Configure JAAS application login entries in WAS
# --------------------------------------------------------------------#
# set up lists of parameters to be set
set aliasList [list Portal_Login Portal_SubjectRebuild]
set loginClass "com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleP
roxy"set loginClassList [list $loginClass $loginClass]
set authStrategy "REQUIRED"
set authStrategyList [list $authStrategy $authStrategy]
set fieldNameList [list delegate delegate]
set fieldValue1 "com.ibm.wps.sso.WebSealLoginModule"
set fieldValue2 "com.tivoli.mts.PDLoginModule"
set fieldValueList [list $fieldValue1 $fieldValue2]
puts "** JAAS Configuration Script **"
#
# Get current cell name - abort if more than 1 cell
#
set cells [$AdminConfig list Cell]
if {[llength $cells] > 1} {
puts "### Error - Script Assumption Violated - More than 1 cell found"
$AdminConfig reset
exit -1
}
set cell [lindex [$AdminConfig list Cell] 0]
set cellname [$AdminConfig showAttribute $cell name]
puts "** Cell Name: $cellname"
# Obtain list of JAAS Application Login Aliases currently defined in the cell
set WAS_appList [$AdminConfig list JAASConfigurationEntry $cell]
#
# Process each of the entries in the aliasList
#
foreach alias $aliasList {
puts "** Processing JAAS Application Login Alias: $alias ..."
# Find Alias
set match 0
foreach appId $WAS_appList {
set a [$AdminConfig showAttribute $appId alias]
if {[string compare $a $alias] == 0} {
set match 1
break
}
}
if {$match != 1} {
puts "### Error - JAAS Application Login Alias $alias not found"
exit -1
}
#
# Process each of the entries in the loginClassList (for the current Alias)
#
foreach i [list 0 1] {
set class [lindex $loginClassList $i]
set auth [lindex $authStrategyList $i]
puts "**** Creating JAAS Login Module ..."
# Create JAAS Login Class for the current Alias
set classAttrib {}
lappend classAttrib [list moduleClassName $class]
lappend classAttrib [list authenticationStrategy $auth]
puts "****** Module: $class"
puts "****** Authn: $auth"
#
# Process the correct custom property for the current Login Class
#
set fieldName [lindex $fieldNameList $i]
set fieldValue [lindex $fieldValueList $i]
puts "****** Name: $fieldName"
puts "****** Value: $fieldValue"
# Create Custom Property for recently created Login Class
set property {}
lappend property [list name $fieldName]
lappend property [list value $fieldValue]
lappend classAttrib [list options [list $property]]
$AdminConfig create JAASLoginModule $appId $classAttrib
}
}
# Save the Configuration Changes
$AdminConfig save
puts "** Configuration changes successfully saved"
puts "** Script Complete **"
Now execute this JACL script as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/wsadmin.sh -user wpsbind -password passw0rd -f /home/amsterdam/config.was.jaas.jacl
WASX7209I: Connected to process "server1" on node amsterdam using SOAP connector; The type of process is: UnManagedProcess
** JAAS Configuration Script **
** Cell Name: amsterdam
** Processing JAAS Application Login Alias: Portal_Login ...
**** Creating JAAS Login Module ...
****** Module: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
****** Authn: REQUIRED
****** Name: delegate
****** Value: com.ibm.wps.sso.WebSealLoginModule
**** Creating JAAS Login Module ...
****** Module: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
****** Authn: REQUIRED
****** Name: delegate
****** Value: com.tivoli.mts.PDLoginModule
** Processing JAAS Application Login Alias: Portal_SubjectRebuild ...
**** Creating JAAS Login Module ...
****** Module: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
****** Authn: REQUIRED
****** Name: delegate
****** Value: com.ibm.wps.sso.WebSealLoginModule
**** Creating JAAS Login Module ...
****** Module: com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy
****** Authn: REQUIRED
****** Name: delegate
****** Value: com.tivoli.mts.PDLoginModule
** Configuration changes successfully saved
** Script Complete **
Confirm that the script output matches that shown above.
Stop and restart the application server “server1”, as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh server1 -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/stopServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh server1
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/server1/startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 7137
Stop and restart the WebSphere® Portal Server (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 1900
2.11 Integrate Credential Vault (Optional)
You can use Tivoli® Access Manager in the Credential Vault service. WebSphere Portal includes a vault adapter for Tivoli® Access Manager.
Note: Users who are storing credentials in the AccessManagerVault must be defined in Tivoli® Access Manager as global signon (GSO) users.
Use these steps to implement the Tivoli® Access Manager vault adapter that is packaged with WebSphere® Portal. The following common variables are used through these steps:
- Make backup copies of the following files (where wp_root is the installation directory for WebSphere® Portal):
- wp_root/shared/app/config/services/VaultService.properties
- wp_root/config/wpconfig.properties
- Verify connectivity to Tivoli® Access Manager by running the validate-pdadmin-connection configuration task.
a. Use a text editor to open the wp_root/config/wpconfig.properties file and enter the appropriate values in the Advanced Security Configuration section of the file.
Note the following:
- Do not change any settings other than those specified in these steps. For instructions on working with these files, see Configuration properties reference for a complete properties reference, including default values.
- Use / instead of \ for all platforms.
- Some values, shown in italics below, might need to be modified to your specific environment.
Input
Description
PDAdminId
The user ID for the administrative TAM user. For example sec_master.
PDAdminPw
The password for the administrative TAM user.
PDPermPath
The location of the TAM AMJRTE properties file.
b. Save the file.
c. Open a command prompt and change to directory was_root/bin.
d. Enter the following commands:
a. startServer server1
b. stopServer WebSphere_Portal -user was_admin_userID -password was_admin_password
e. Change to the directory wp_root/config.
f. Enter the following command to run the appropriate configuration task for your specific operating system:
- UNIX: ./WPSconfig.sh validate-pdadmin-connection -DPdAdminPw=password
Note: If the configuration task fails, validate the values in the wpconfig.properties file.
- If the validate-pdadmin-connection task succeeds, skip to step 4. If the validate-pdadmin-connection task fails, do the following:
. Use a text editor to open the wp_root/config/wpconfig.properties file and enter the appropriate values in the Advanced Security Configuration section of the file. Do not change any settings other than those specified in these steps.
Input
Description
PDServerName
Unique application name used to create a new Tivoli® server in the Access Manager Policy Server.
Note: If a server with the same name appears in the server list command, the SvrSslCfg command will fail.PDAdminId
The user ID for the administrative TAM user. For example sec_master.
PDAdminPw
The password for the administrative TAM user.
PDPermPath
The location of the TAM AMJRTE properties file.
SvrSslCfgPort
Configuration port for the application name.
SvrSslCfgMode
Configuration mode of the SvrSslCfg command.
PDPolicyServerList
Defines a hostname, port, and priority combinations for your TAM Policy servers used when running SvrSslCfg.
PDAuthzServerList
Defines a hostname, port, and priority combination for your TAM authorization servers.
PDKeyPath
Stores encryption keys used for the SSL communication between AMJRTE and
Tivoli® Access Manager.a. Save the file.
b. Open a command prompt and change to directory was_root/bin.
c. Enter the following commands:
- startServer server1
- stopServer WebSphere_Portal -user was_admin_userID -password was_admin_password
d. Change to the directory wp_root/config.
e. Enter the following command to run the appropriate configuration task for your specific operating system:
- UNIX: ./WPSconfig.sh run-svrssl-config -DPdAdminPw=password
- Windows: WPSconfig.bat run-svrssl-config -DPdAdminPw=password
Note: If the configuration task fails, validate the values in the wpconfig.properties file.
- Configure the Credential Vault adapter.
. Use a text editor to open the wp_root/config/wpconfig.properties file and enter the appropriate values in the Advanced Security Configuraiton section. Do not change any settings other than those specified in these steps.
Input
Description
PDAdminId
The user ID for the administrative TAM user. For example sec_master.
PDAdminPw
The password for the administrative TAM user.
PDPermPath
The location of the TAM AMJRTE properties file.
a. Save the file.
b. Open a command prompt and change to directory was_root/bin.
c. Enter the following commands:
- startServer server1
- stopServer WebSphere_Portal -user was_admin_userID -password was_admin_password
d. Change to the directory wp_root/config.
e. Enter the following command to run the appropriate configuration task for your specific operating system. This configuration task automatically creates and populates a file named wp_root/shared/app/config/accessmanagervault.properties:
- UNIX: ./WPSconfig.sh enable-tam-vault -DPDAdminPw=password
- Windows: WPSconfig.bat enable-tam-vault -DPDAdminPw=password
Note: If the configuration task fails, validate the values in the wpconfig.properties file.
- Optional: Use the WebSphere® Application Server encoding mechanism to mask the passwords in the production version of the file. Refer to the detailed instructions in Password masking for masking passwords, changing masked passwords, or running commands with explicit password properties.
- Verify that AccessManagerVault can access the GSO lockbox from within WebSphere® Portal by running the validate-pdadmin-connection configuration task.
. Use a text editor to open the wp_root/config/wpconfig.properties file and enter the appropriate values in the Advanced Security Configuration section.
Input
Description
PDAdminId
The user ID for the administrative TAM user. For example sec_master.
PDAdminPw
The password for the administrative TAM user.
PDPermPath
The location of the TAM AMJRTE properties file.
a. Save the file.
b. Open a command prompt and change to directory was_root/bin.
c. Enter the following commands:
- startServer server1
- stopServer WebSphere_Portal -user was_admin_userID -password was_admin_password
d. Change to the directory wp_root/config.
e. Enter the following command to run the appropriate configuration task for your specific operating system:
- UNIX: ./WPSconfig.sh validate-pdadmin-connection -DPdAdminPw=password
- Windows: WPSconfig.bat validate-pdadmin-connection -DPdAdminPw=password
Note: If the configuration task fails, validate the values in the wpconfig.properties file.
2.11.1 Test the Configuration
2.11.1.1 Create a Test Credential Segment and Slot
We will now create a test segment and slot in the WPS credential vault and link it to a specific TAM GSO Resource (i.e. a specific target location in the TAM GSO lockbox).
Open WPS in a browser, and log in as “wpsadmin” (password “wpsadmin”).
Press the “Administration” link on the top line of the screen.
Select the “Access” link in the left-hand navigation panel.
Select the “Credential Vault” link from the left-hand navigation panel.
Press the button associated with “Add a vault segment”.
Ensure the “AccessManager (0)” entry is selected in the “Vaults” pull-down list. Enter “WPS-TAM Segment” in the “Vault segment name” field and press “OK” to add the new vault segment.
Press the button associated with “Add a vault slot”.
Ensure the “AccessManager” entry is selected in the “Vault” pull-down list and “WPS-TAM Segment” is selected in the “Vault segment” pull-down list.
Select the “new” [Vault resource] radio button and enter “WPS-TAM GSO Resource” in the associated field. Enter “WPS-TAM Vault Slot” in the “Name” field.
Press “OK” to add the new vault slot in WPS and create the new resource in the TAM GSO lockbox.
Select the “Log out” link to in the top right corner of the screen.
Note: To confirm the GSO Resource was created you can use the “rsrc list” command versus the GUI steps listed below.
We will now confirm that the GSO Resource was created in TAM. Display the following URL in a browser: https://amsterdam.ibm.com:444/pdadmin.
Enter “sec_master” and “passw0rd” in the “User ID” and “Password” fields and press the “Login” button.
Expand the “GSO Resource” menu group and select “List->GSO” from the left-hand navigation panel.
You should now see the GSO resource we specified when we created the vault slot in WPS.
Select the “Sign Off” link (in the bottom right-hand corner of the screen) and close the browser.
2.12 Integrate Authorization (Optional)
NOTE: This section has not been tested against WPS5.1 but has been left here for reference.
There are two different ways to view authorization of WebSphere® Portal resources:
· access to portal resources is part of enterprise security and needs to be centrally controlled and managed;
· access control functionality in a portal is simply used to modify the user experience for different sets of users, and is therefore a component of GUI design and not part of the realm of enterprise security.
In many real-world environments, the real answer is likely to be some combination of these two alternatives. It is unlikely that access control for all portal resources falls in the realm of enterprise security (e.g. Welcome page, World Clock portlet, private pages); however, there may be mission-critical or other sensitive pages/portlets that are considered part of the enterprise security domain within an organization. This latter case typically arises where portlets dealing with sensitive data have been designed such that access to the portlet automatically implies access to the full function of the portlet (without any further authorization based on individual user identity), or where a defense-in-depth approach is required.
WebSphere® Portal provides built-in access control functionality for managing access to the portal resources it is hosting. The entitlement data is stored in the portal database (in our case Cloudscape) and managed via administration portlets.
WebSphere® Portal also provides the ability to move access control for specific portal resources to Tivoli® Access Manager. WebSphere Portal invokes the Access Manager authorization APIs for authorization decisions relating to these resources. This allows an organization to manage access control for sensitive pages and portlets using the same semantics and utilities as that used for the other enterprise security resources managed via Access Manager.
In this optional section, we will configure WebSphere Portal to allow authorization of specific resources to be moved to Tivoli Access Manager. For those readers who have integrated authorization of WPS version 4 resources with TAM, you will notice significant differences in the results produced in TAM for WPS version 5 resources.
2.12.1 What External Authorization Means
Even in the case where authorization for a particular resource has been externalized to TAM, WPS still controls the authorization decision. WPS simply uses the TAM entitlements service to determine what WPS roles the current user has been granted (for the particular resource).
I therefore recommend that you become familiar with the standard WPS authorization logic and terminology ‑ refer to the WebSphere® Portal InfoCenter for details:
http://www-1.ibm.com/support/search.wss?rs=688&tc=SSHRKX&dc=D400&rankprofile=8&dtm.2.12.2 Apply WPS Patch PQ86200
At the time of writing this guide, a new patch was in the process of being released for WPS 5.0.2.1 that added additional usability options to the external authorization interface of WPS. It is strongly recommended that this patch (PQ86200) be applied if you intend using the external authorization functionality of WPS. Patch PQ86200 will be available at the following site:
http://www-1.ibm.com/support/search.wss?rs=688&tc=SSHRKX&dc=D400&rankprofile=8&dtm
Stop the WebSphere® Portal Server as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind -password passw0rd
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
Assuming you downloaded the efix file “PQ86200.jar” to “/tmp”, the fix can be applied to WPS as follows (commands are shown in bold):
# cd /opt/WebSphere/PortalServer/shared/app
# jar xvf /tmp/PQ86200.jar
created: META-INF/
inflated: META-INF/MANIFEST.MF
created: com/
created: com/ibm/
created: com/ibm/wps/
created: com/ibm/wps/ac/
created: com/ibm/wps/ac/esm/
inflated: com/ibm/wps/ac/esm/TAMExternalAccessControlImpl.class
created: com/ibm/wps/ac/authtable/
inflated: com/ibm/wps/ac/authtable/WPTAMAuthTableImpl$ESMEntitlementsCache.c
lassinflated: com/ibm/wps/ac/authtable/WPTAMAuthTableImpl.class
inflated: com/ibm/wps/ac/esm/GenericExternalAccessControlImpl.class
Restart the WebSphere Portal Server (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 34567
2.12.3 Configure WPS for TAM-Based Authorization
2.12.3.1 Configuration Options Selected
There are a variety of options for configuring WPS for external authorization to TAM. Below is a brief discussion of the key options, along with the settings selected for this guide.
Externalize All Roles Option
By default, when a WPS resource is externalized to TAM, the Administrator role and any other roles with explicit permissions set on the WPS resource are externalized to TAM (with TAM objects created for those roles). Any roles associated with the WPS resource that do not have explicit permissions set will remain solely under WPS access control. These roles can be moved to TAM by going back into the resource permissions portlet for the resource and clicking a button next to each role.
In my opinion, having some roles controlled solely by WPS and other roles externalized to TAM for a specific resource would likely cause confusion in administering/auditing access control rights for the resource.
WPS 5.0.2.1 introduced a new feature where all roles for a resource can be moved to TAM in one step, regardless of whether or not explicit permissions were set on a particular role. We will later set the “accessControlDataManagement.externalizeAllRoles” parameter to “true” to enable this feature.
Reorder Role Name Components Option
WPS 5.0.2.1 supports two formats of TAM object names for objects created by WPS when a role is externalized to TAM. For example:
1) Administrator@WEB_MODULE_Tracing.war_1_0_3K
2) WEB_MODULE_Tracing.war_1_0_3K@Administrator
Note that the “Administrator@VIRTUAL_wps.EXTERNAL_ACCESS_CONTROL_1” object, which is automatically created on the first restart of WPS after external access control has been enabled, is always created using the first format, regardless of the format selected for other objects.
Option 1 is the default, and it groups objects (when their names are sorted alphabetically) of the same role type together. Whereas option 2 groups objects for all of the roles for a particular WPS resource instance together.
We will later set the parameter “accessControlDataManagement.reorderRoleNames” to “true” to enable option 2.
ACL Creation Option
WPS provides a facility where it will create and attach a TAM ACL to an object that it creates in the TAM object space for a particular role. This feature can be disabled, in which case no ACL is created.
Ideally in a production environment, you would seek to reuse ACLs and utilize TAM ACL inheritance wherever possible to simplify your security policy; in which case, you would likely disable this feature. On the other hand, if you enable this feature, WPS will create the ACL such that it contains any explicit role permissions that were defined for the corresponding WPS resource before it was externalized; however, it will not include any inherited role permissions.
As we are building a demonstration/test system in this document, we will later set the “externalaccesscontrol.createAcl” parameter to “true” to enable automatic TAM ACL creation by WPS.
Optional Context Data
WPS 5 introduced a new (role-based) access control model, which led to a new model for externalizing authorization to TAM. Part of this new externalization model included the addition of three levels of child objects under the role object to indicate context. PQ86200 allows this context information to be omitted.
As these context values serve no useful purpose in our demonstration/test system, we will later omit the context definition parameters in “ExternalAccessControlService.properties”, which will cause the context child objects to not be created by WPS.
WPS Instance Name Option
PQ86200 introduced a feature that allows an additional TAM object container to be inserted between the WPS root object and the role objects. This feature was added to allow multiple WPS servers to share the same TAM objectspace in a similar manner to that of other TAM blades (e.g. WebSEAL).
We will not define the parameter “externalaccesscontrol.instance” in our system; thereby effectively disabling this feature for our system.
Rolename Substring Search Option
PQ86200 introduced a feature that allows WPS to be configured such that it only searches for the rolename component of the TAM object name (i.e. not the fully-qualified TAM object name that it had earlier created) in the results of the TAM entitlements query when determining a user’s access rights.
This feature has the potential to allow much greater use of TAM inheritance for WPS roles; however, we will later set the “externalaccesscontrol.allowSubStringSearch” parameter to “false” to disable this feature for our demonstration/test system.
ACL Cache Timeout
WPS allows a timeout value to be defined to set the amount of time that WPS will cache the results of a TAM entitlements service call (which was called to help determine the roles for the current user). We will later set the “accessControlDataManagement.cacheTimeout” parameter to 30 (seconds). Production systems would typically use much higher values for this parameter.
Nested Groups
WPS can optionally support nested LDAP groups. As TAM 5.1 does not support nested groups, we will later set the “accessControlDataManagement.enableNestedGroups” parameter to “false”; thereby ensuring that our LDAP group definitions are fully usable in both products.
2.12.3.2 Modify WPS Properties Files
Modify “ExternalAccessControlService.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/shared/app/config/services/ExternalAccessControlService.properties…
externalaccesscontrol.ready=true
…
externalaccesscontrol.pdroot=/WPSv5
…
externalaccesscontrol.pduser=sec_master
externalaccesscontrol.pdpw=passw0rd
…
externalaccesscontrol.pdurl=file:/opt/WebSphere/AppServer/java/jre/PdPerm.properties
…
externalaccesscontrol.createAcl=true
…
externalaccesscontrol.pdactiongroup=[WPS]
externalaccesscontrol.pdaction=m
externalaccesscontrol.allowSubStringSearch=false
…
Modify “AccessControlConfigService.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/shared/app/config/services/AccessControlConfigService.properties# @copyright properties
# ----------------------------------------------- #
# Properties of the Access Control Config Service #
# ----------------------------------------------- #
# This setting activates driving the ExternalAccessControlService SPI
# Supported values: true, false (default: false)
accessControlConfig.enableExternalization=true
…
Modify “AccessControlDataManagementService.properties”
Modify the values shown in bold below in:
/opt/WebSphere/PortalServer/shared/app/config/services/AccessControlDataManagementService.properties”:
…
# This setting determines if the group membership of groups is exploited by the
# Portal Access Control Component.
# Supported values: true, false (default: true)
accessControlDataManagement.enableNestedGroups=false
…
# This setting determins the wait time in seconds between two
# periodic access control cache flushes. If no periodic cash
# flushes shall occur, this property has to be set to 0.
# Activating this feature is required when using an external
# authorization provider (e.g. Tivoli® Access Manager)
# (default: 0)
accessControlDataManagement.cacheTimeout=30
…
accessControlDataManagement.externalizeAllRoles=true
accessControlDataManagement.reorderRoleNames=true
Modify “services.properties”
Modify the values shown in bold below in
/opt/WebSphere/PortalServer/shared/app/config/services.properties
…
# Access Control
com.ibm.wps.services.ac.internal.AccessControlDataManagementService = com.ibm.
wps.ac.impl.AccessControlDataManagementServiceImplcom.ibm.wps.services.ac.PermissionFactoryService = com.ibm.wps.ac.impl.Permiss
ionFactoryImplcom.ibm.wps.services.ac.ACPrincipalFactoryService = com.ibm.wps.ac.impl.ACPrin
cipalFactoryImplcom.ibm.wps.services.ac.ExternalAccessControlService = com.ibm.wps.ac.esm.TAM
ExternalAccessControlImpl…
2.12.3.3 Create TAM Actions for WPS
WPS-specific action group and action characters must be defined in Access Manager prior to integration of authorization with WPS.
Create a temporary file (“/home/amsterdam/create.actions.pd”) containing the following “pdadmin” commands ‑ [Note: This file is in the ZIP archive embedded in this document]:
action group create WPS
action create "m" "Member of" Portal WPS
Now execute the “pdadmin” script file as follows (commands are shown in bold):
# pdadmin -a sec_master /home/amsterdam/create.actions.pd
Enter Password:passw0rd
cmd> action group create WPS
cmd> action create "m" "Member of" Portal WPS
2.12.4 Confirm TAM ObjectSpace Entries Created for WPS
Stop and restart the WebSphere® Portal Server as follows (commands are shown in bold):
# /opt/WebSphere/AppServer/bin/stopServer.sh WebSphere_Portal -user wpsbind
-password passw0rdADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/stopServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server WebSphere_Portal stop completed.
# /opt/WebSphere/AppServer/bin/startServer.sh WebSphere_Portal
ADMU0116I: Tool information is being logged in file
/opt/WebSphere/AppServer/logs/WebSphere_Portal/startServer.log
ADMU3100I: Reading configuration for server: WebSphere_Portal
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server WebSphere_Portal open for e-business; process id is 1900
#
Confirm that WebSphere® Portal is still operating correctly: open a browser and display the public portal page; login as “wpsadmin”; and then logoff.
We will also confirm that the WPS object space entries were created in TAM. Display the following URL in a browser: https://amsterdam.ibm.com:444/pdadmin.
Enter “sec_master” and “passw0rd” in the User ID and Password fields and press the “Login” button.
Expand the “Object Space” menu group and select “Browse” from the left-hand navigation panel.
Expand the “/” object in the Object Space (by clicking the plus sign next to the object name), then expand all items under the “WPSv5” entry.
Confirm that the entries shown in the above screen image appear in your system.
Select the “Sign Off” link in the bottom right-hand corner of the page and close the browser.
2.12.5 Test External Authorization to TAM
In this section we will perform a simple test to confirm that the externalization of WPS resources to TAM has been configured correctly. We will use the “My Stocks” portlet for our test. We will externalize the portlet, confirm the correct TAM objects were created, then internalize the resource back under WPS control.
Open WPS in a browser, and log in as “wpsadmin” (password “wpsadmin”).
Select the “Administration” link in the top right-hand corner of the page.
Select the “Access” link in the left-hand navigation panel.
Select the “Resource Permissions” link in the left-hand navigation panel.
Select the “Portlets” link under the list of Resource Types.
Enter “stocks” in the “Search for” field and press the “Search” button.
Select the right-arrow icon button for the “My Stocks” portlet.
Press “OK” to continue.
You should now see a message indicating that the resource has been successfully externalized, as shown above.
Press the “Done” button.
We will now confirm that the correct objects were created in TAM. Open a new browser window and display the following URL: https://amsterdam.ibm.com:444/pdadmin.
Enter “sec_master” and “passw0rd” in the User ID and Password fields and press the “Login” button.
Expand the “Object Space” menu group and select “Browse” from the left-hand navigation panel.
Expand the “/” object in the Object Space (by clicking the plus sign next to the object name), then expand all items under the “WPSv5” entry.
You should now see 7 objects (one per WPS role) for the “My Stocks” portlet, as shown above.
Click the ACL name next to the “PORTLET_DEFINITION_MyStocks_3_0_4C@Administrator” object.
This is the ACL that was automatically created by WPS. Confirm that an ACL entry for “wpsadmin” was created by WPS, as shown above.
Select the “Browse Object Space” link in the left-hand navigation panel.
Select the “Browse Object Space” link in the left-hand navigation panel.
Return to the WPS browser window.
Select the “Portlets” link under the list of Resource Types.
Enter “stocks” in the “Search for” field and press the “Search” button.
Note that the arrow icon associated with the “My Stocks” portlet now faces left ‑ this indicates that the resource has been externalized. Press this left-arrow icon.
Press “OK” to continue.
You should now see a message indicating that the resource has been successfully internalized, as shown above.
Press the “Done” button.
Select the “Log out” link in the top right-hand corner of the page.
We will now confirm that the TAM objects for the resource we just internalized back into WPS have been deleted from the TAM objectspace. Return to the WPS browser window.
Press the “Refresh” button to refresh the TAM object space.
Expand the “/” object in the Object Space (by clicking the plus sign next to the object name), then expand all items under the “WPSv5” entry.
You should now see that the TAM objects for the “My Stocks” portlet have been removed from the object space.
Select the “Sign Off” link in the bottom right-hand corner of the page.
Our simple test of external authorization is now complete.
® WebSphere is a trademark of the IBM® Corporation in the United States, other countries, or both.
® IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
® Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.