ShowTable of Contents
Introduction
Virtual host junctions from the IBM® Tivoli® Access Manager for e-business (TAMeb) WebSEAL product are recommended for use with virtual portals since they provide advantages such as the ability to map a virtual host name to each virtual portal and to share sessions across portal instances, if required. Hence users are provided with seamless movements across virtual portals without the need to re-authenticate.
Virtual host junctions are also recommended when there are Java
TM applets or Java scripts contained in a portlet that use absolute URL's and thus will fail to paint with a standard junction.
Prerequisites
You should have the following installed:
-
IBM WebSphere® Portal V7
-
TAMeB v6.1.1
-
TAM Session Management Server (SMS), and a replica set configured
For more details, refer to the “Installation Guide for IBM Tivoli Access Manager for e-business 6.1.1” and the installation instructions for WebSphere Portal on the WebSphere portal wiki.
Integrating WebSphere Portal 7.0 and TAMeB 6.1.1
Integrating WebSphere Portal with a standalone TDS (LDAP)
To do this:
1. Install the Tivoli Directory Server (TDS) client rpm files on the machine where WebSphere Portal is installed. Note that TDS version 6.1.0.6 or later is required in order to work with TAM 6.1.1:
-
idsldap-clt32bit61-6.1.0-42.x86_64.rpm
-
idsldap-clt64bit61-6.1.0-42.x86_64.rpm
-
idsldap-cltbase61-6.1.0-42.x86_64.rpm
-
idsldap-cltjava61-6.1.0-42.x86_64.rpm
2. Create Portal users in LDAP using the portalusers.ldif file available with the Portal installer:
./idsldap -D cn=root -w tds123 -f portalusers.ldif
3. Configure WebSphere Portal to use TDS as a standalone registry:
a) First, change the /opt/IBM/WebSphere/wp_profile/ConfigEngine/config/helpers/wp_security_ids.properties file parameters listed in table 1 to the values shown. Note that these entries are required; others are optional can be left to their defaults.
Table 1. Required entries
|
|
|
Specifies unique identifier for the repository within the cell
|
|
Host name or IP address of the machine on which TDS is installed
|
|
The port number of LDAP default is 389 (non-secure)
|
|
The distinguished name for WebSphere Application Server (WAS) to use when binding with LDAP
|
standalone.ldap.bindPassword
|
The password for the binding user
|
standalone.ldap.ldapServerType
|
Specify the IBM Directory Server (IDS) for Tivoli Directory Server
|
|
Specify the distinguished name for WAS to use when binding to LDAP repository.
|
|
A security context for the Portal server
|
standalone.ldap.serverPassword
|
Specify the password for the above
|
standalone.ldap.primaryAdminId
|
The user ID of the WAS administrator **
|
standalone.ldap.primaryAdminPassword
|
The password for WAS administrator **
|
standalone.ldap.primaryPortalAdminId
|
The user ID of the Portal administrator **
|
standalone.ldap.primaryPortalAdminPassword
|
The password for Portal administrator. **
|
standalone.ldap.primaryPortalAdminGroup
|
The group for Portal administrator users **
|
|
|
** These parameters must be same as the entries inserted in Step 2 above (the contents of the file portalusers.ldif); all the other parameters can be left to their defaults
Once the wp_security_ids.properties is ready, use it as a parentProperties file to execute the “validate LDAP” task, which makes sure that the values of your settings are OK:
./ConfigEngine.sh validate-standalone-ldap -DWasPassword=wasadmin -DparentProperties=/software/IBM/WebSphere/wp_profile/ConfigEngine/config/helpers/wp_security_ids.properties
Once the validation is successful, you can execute the wp-modify-ldap-security task to enable the Portal server to use TDS as a standalone registry:
./ConfigEngine.sh wp-modify-ldap-security -DWasPassword=wasadmin
Integrating and configuring WebSphere Portal with TAM and WebSEAL
To do this:
1. Install the following rpms:
PDJrte-PD-6.1.1-0.i386.rpm
gsk7bas-7.0-4.28.i386.rpm
ibm-java-sdk-6.0-8.1-linux-i386.rpm
Pdlic-PD-6.1.1-0.i386.rpm
PDMgr-PD-6.1.1-0.i386.rpm
PDRTE-PD-6.1.1-0.i386.rpm
TivSecUtl-TivSec-6.1.1-0.i386.rpm
2. Follow the instructions in the InfoCenter topic, “Creating the AMJRTE properties file,” to create Java runtime for TAM from WebSphere Portal.
3. Enter only the following parameters in the wkplc_comp.properties file under the WebSEAL junction parameters heading:
-
For wp.ac.impl.JunctionType, type tcp or ssl, to define the type of junction to be created in TAM.
-
For wp.ac.impl.JunctionPoint, type the WebSEAL junction point to the WebSphere Portal installation (for example, / ,/wps). Because we later convert it to a transparent path junction, it should be maintained as the same as the backend server's path, so / (root) is recommended for our scenario.
-
For wp.ac.impl.WebSEALInstance, type the WebSEAL instance name that will be used to create the junction. You can obtain this by running the server list command from the pdadmin command-line utility.
-
For wp.ac.impl.TAICreds, type the headers inserted by WebSEAL that the Trust Association Interceptor (TAI) uses to identify the request as originating from WebSEAL. Default values are (iv-user, iv-groups).
-
For wp.ac.impl.JunctionHost, type the backend server hostname to supply to the junction create command.
-
For wp.ac.impl.JunctionPort, type the backend server port to supply to the junction create command; that is, the port number where Portal is deployed.
4. Enter only the following parameters in the wkplc_comp.properties file under the WAS WebSEAL TAI parameters heading:
-
For wp.ac.impl.loginId, type the reverse proxy identity used when you created a TCP junction (sec_master).
Specifying a user ID: The user ID you specify must be an existing user in the LDAP directory that WAS security can authenticate and must also be registered and validated in TAM. WebSEAL requires this user ID to authenticate with WAS security.
-
For wp.ac.impl.BaUserName, type the reverse proxy identity used when you create an SSL junction (sec_master).
Specifying a user ID: Same as for the above.
-
For wp.ac.impl.BaPassword, type the password for the wp.ac.impl.BaUserName (temp4now). This password also needs to be added to the WebSEAL config file described later in this article.
5. Enter only the following parameters in the wkplc_comp.properties file under the Portal authorization parameters heading:
-
For wp.ac.impl.PDRoot, type the root object space entry in the TAM namespace. All Portal roles will be installed under this objectspace entry. If you will be using TAM for multiple profiles, choose a unique name for each root objectspace entry, to easily distinguish one entry from another profile entry (/WPS)
-
For wp.ac.impl.PDAction, type the Custom Action created by the TAM external authorization plug-in. The combination of the action group and the action determines the TAM permission string required to assign membership to externalized portal roles (m).
-
For wp.ac.impl.PDActionGroup, type the Custom Action group created by the TAM external authorization plug-in. The combination of the action group and the action determines the TAM permission string required to assign membership to externalized portal roles ([WPS]).
-
For wp.ac.impl.PDCreateAcl, type “true” to automatically create and attach a TAM ACL when WebSphere Portal externalizes a role, or “false” to not create and attach a TAM ACL when WebSphere Portal externalizes a role (true).
-
For ConfigEngine.sh, enable-tam-all -DWasPassword=password from the wp_profile_root\ConfigEngine directory.
Making protected/unprotected WebSphere Portal landing pages from WebSEAL using ACL's
To do this:
1. Set the following properties in WebSEAL config file, webseald-default.conf:
-
dynurl-allow-large-posts = yes. If this option is set to "yes", then WebSEAL will compare only up to request-body-max-read bytes of a POST request to the URL mappings in the dynurl.conf file.
-
forms-auth = both. Enables forms-based authentication, so that a user is required to submit his credentials in a form to the WebSEAL server.
-
ba-auth = none. Disables basic authentication since we have enabled forms-based authentication.
-
basicauth-dummy-passwd = temp4now. Make sure the value supplied here is the same as the argument supplied when you configured TAM integration in Portal (that is, the wp.ac.impl.BaPassword property from the previous section).
-
allow-unauthenticated-logout = yes. This is required since we are changing the logout page of WebSphere Portal.
-
allow-unauth-ba-supply = yes. This is required since we are creating an unauthenticated landing page in WebSEAL without which Portal doesn't paint the unprotected page.
-
dsess-enabled = yes. Enables integration with the distributed SMS.
-
standard-junction-replica-set = webseal.us.ibm.com. Enter the value for the default replica set that you configured when installing the SMS.
2. From the pdadmin command line utility, do the following:
a) Convert the junction created by WebSphere Portal to the transparent-path-junction server task, default-webseald-webhost create -t tcp -p 10039 -h portal.us.ibm.com -c all -b supply -x /
where:
-p is the port of WebSphere Portal server
-h represents the host name of WebSphere Portal
-c all, passes all the headers
-b supply, supplies TAI credentials
-x makes it a transparent path junction
b) Create an ACL for unprotected access:
acl create unprotected
acl modify unprotected set any-other Trx
acl modify unprotected set unauthenticated Trx
acl modify unprotected set wpsadmins Trx
acl modify unprotected set description "ACL for anonymous access"
c) Assign it to the page, which must be unprotected (that is, /wps/portal), by assigning the ACL to the /wps/portal object:
acl attach /WebSEAL /webseal-default/ unprotected
acl attach /WebSEAL /webseal-default/wps/portal unprotected
and make the /wps/myportal page protected by assigning default-webseal ACL:
acl attach /Webseal/webseal-default/wps/myportal default-webseal
Changing the log-out page of Portal to point to the log-out page of WebSEAL reverse proxy
The next step is to modify the log-out page of WebSphere Portal to point to a WebSEAL log-out page so that when a user logs out of Portal he also logs out of WebSEAL:
1. Log in to the admin console and select Resource Environment Providers under the Resources section (see figure 1).
2. Select WP_ConfigService --- Custom properties, and insert the following attributes and their values:
redirect.logout = true
redirect.logout.ssl =true
redirect.logout.url = (URL of WebSEAL machine)
Figure 1. Modifying Portal log-out pages

3. Modify the logout.html from the /opt/pdweb/www-default/lib/html/C to redirect to the Portal unprotected page (portal.us.ibm.com/wps/portal). The sample code in listing 1 clears cookies and redirects to Portal:
Listing 1. Sample code
var exception_list = "";
function delete_cookie (name, path)
{
// Set expiration date to last month
var exp_date = new Date ();
exp_date . setMonth (expi_date . getMonth () - 1);
exp_date = exp_date . toGMTString ();
// Expire the cookie
var cookie_string = name + "=; expires=" + exp_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)
{
var cookie_string = "" + document . cookie;
var cookie_array = cookie_string . split ("; ");
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="3;URL=http://portal.us.ibm.com/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> %USERNAME% has logged out.</b></font>
<BR><BR>
<BR><BR>
Redirecting to public portal page ... select <a
href="http://portal.us.ibm.com/wps/portal">here</a> if your browser does not
automatically redirect after 3 seconds.
</body>
</html>
SSO to WebSphere Portal from WebSEAL is now achieved. In the next section we create the virtual host junctions.
Applying the concept of virtual host junction to Portal and virtual portals
Virtual host junctions
Server-related links have the advantage that the browser connects to the WebSEAL server to retrieve them. With absolute links, however, the browser attempts to resolve a different name to an IP address and to connect to that address. To avoid this situation, we use virtual host junctions, which are junctions that WebSEAL identifies by using the
host: HTTP header instead of using a directory name.
With virtual host junctions, multiple host names (for example,
www.portal.com and
www.virtual.portal.com) resolve to the IP address for WebSEAL. When WebSEAL receives the request, the HTTP header contains a
host: field that corresponds to the host part of the URL. For example, if the browser tries to retrieve
http://www.virutal.portal.com/page1.html, the HTTP request will look like the following:
www.virtual.portal.com
With this method, WebSEAL can receive absolute links and then deal with them correctly.
Suppose we have two portal hostnames, one main portal and one virtual portal, named portal.ibm.com and virtual.portal.ibm.com, respectively. Then we can follow the steps below to create the topology as shown in figure 2.
Figure 2. WebSEAL virtual-host-junction names mapped to Portal server host names

1. To create virtual host junctions to each of the portal instances, that is, the main portal and the virtual portal, we issue the following commands:
server task default-webseald-webhost virtualhost create -t tcp -h portal.us.ibm.com -z
webseal.ibm.com -v portal.ibm.com -p 10104 -c all -b supply -f virtual-bioportal
-t indicates the type of protocol used (tcp, ssl)
-h indicates the backend server's host name
-z indicates the replica set to be used by WebSEAL to maintain a session for this particular junction
-v indicates the virtual hostname to be entered by the user in their browser, to log into the WebSEAL server
2. Similarly, create a virtual host junction for the virtual portal, using these commands:
server task default-webseald-webhost virtualhost create -t tcp -h virtual.portal.us.ibm.com -z webseal.ibm.com -v virtual.portal.ibm.com -p 10104 -c all -b supply -f virtual-bioportal1
3. Apply the ACLs to create protected and unprotected landing pages for both virtual host junctions:
acl attach /WebSEAL /webseal-default/@virtual-bioportal/ unprotected
acl attach /WebSEAL /webseal-default/@virtual-bioportal/wps/portal unprotected
acl attach /WebSEAL /webseal-default/@virtual-bioportal/wps/myportal default-webseal
acl attach /WebSEAL /webseal-default/@virtual-bioportal1/ unprotected
acl attach /WebSEAL /webseal-default/@virtual-bioportal1/wps/portal unprotected
acl attach /WebSEAL /webseal-default/@virtual-bioportal1/wps/myportal default-webseal
Note that virtual host junction objects begin with '@' in WebSEAL.
Exceptional conditions
If there is a need to change the port numbers of Portal, run the following commands:
./ConfigEngine.sh modify-ports-by-startport -DModifyPortsServer=server1 -DStartPort=10070 (new port)
./ConfigEngine.sh modify-ports-by-startport -DModifyPortsServer=WebSphere_Portal -DstartPort=10090 (new port)
If, after following all the above steps, WebSphere Portal fails to paint, then apply the following changes
in the WebSEAL configuration file under [interfaces] stanza, adding the following line:
interface1 = network-interface=192.168.12.22; http-port=10104
where “network-interface” indicates the IP of the machine where portal is deployed, and “http-port” is the port where Portal is running.
Restart WebSEAL by running the “pdweb restart” command.
Conclusion
This article has explained how to integrate WebSphere Portal with TAMeB, using virtual host junctions, and described the various configuration steps necessary and the advantages of virtual host junctions over standard junctions.
Resources
developerWorks WebSphere Portal zone:
http://www.ibm.com/developerworks/websphere/zones/portal/
Tivoli Information Center:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp
TAM tracing and debugging:
http://www.ibm.com/developerworks/tivoli/library/t-tamtrace/index.html
About the authors
Bharath Kumar Devaraju is currently working on InfoSphere Streams and has 2.5 years of experience with IBM. He also has worked as a software developer and security solution designer for DAAS (Data As a Service) as part of IBM's Cloud Computing Initiative. Bharath is also a QualityStage and DataStage Certified Solution developer, and has worked extensively on customer POC's and assisted in pre-sales activities for Growth markets. You can reach him at bhdevara@in.ibm.com.
Mohan N Dani is currently leading the DAAS Cloud Computing efforts, InfoSphere Streams, and has more than 11 years of experience in IT. He has extensive knowledge of implementing large enterprise solutions and has served in multiple roles as an IBM Business Analyst, Development Lead, and Solution Architect, specializing in data quality. He also consults for IBM Internal teams for Pre-sales, Post-sales and Delivery Excellence, and Thought leadership on Data Quality. You can reach him at mohadani@in.ibm.com.