Skip to main content link. Accesskey S
  • Log In
  • Help
  • IBM Logo
  • IBM Digital Experience wiki
  • All Wikis
  • All Forums
  • Home
  • Product Documentation
  • Community Articles
  • Learning Center
  • IBM Redbooks
  • API Documentation
Search
Community Articles > WebSphere Portal > Deployment Scenarios for WebSphere Portal > Integrating IBM Tivoli Access Manager for e-business 6.1.1 and IBM WebSphere Portal 7.0 using virtual host junctions
  • New Article
  • Share Show Menu▼
  • Subscribe Show Menu▼

About the Original Author

Click to view profileIBM contributorLeslie Gallo
Contribution Summary:
  • Articles authored: 30
  • Articles edited: 14
  • Comments Posted: 0

Recent articles by this author

Collecting performance measurements of your IBM WebSphere - Java Virtual Machine

This article discusses an example of creating a collection of IBM WebSphere Portal performance measurements, using the Administrator Thin Client to running a jython script for collecting the desired data.

Integrating IBM WebSphere Portal 7 with Microsoft SharePoint 2010

This article explains how to integrate the portal frameworks between IBM WebSphere Portal, which is based on the J2EE programming model, and Microsoft SharePoint, which is based on the .NET programming model.

IBM WebSphere Portal 7 customization scenario: Part 1, Customizing a menu portlet

During an IBM WebSphere Portal implementation, customization is typically required in a few areas. This article explains how to build a customized WebSphere Portal menu in a JSR portlet, using WebSphere Portal 7 APISPIs.

Increasing the Search Engine Optimization ranking for IBM Web Content Manager Web sites

Learn how how you can remove both the traditional 301 (0 302) redirect from a Web site root to an IBM Web Content Manager URL and the common path part from the URL, such as wcpwcmconnectlibraryName.

Performance management tools for IBM WebSphere Portal

This document details the tooling that was used during a recent performance-related customer engagement. It describes the tools and how they were used to evaluate IBM WebSphere Portal 7 performance problem determination issues.
Community articleIntegrating IBM Tivoli Access Manager for e-business 6.1.1 and IBM WebSphere Portal 7.0 using virtual host junctions
Added by IBM contributorLeslie Gallo | Edited by IBM contributorDeAnna Steiner on September 13, 2012 | Version 9
  • Edit
  • More Actions Show Menu▼
Rate this article 1 starsRate this article 2 starsRate this article 3 starsRate this article 4 starsRate this article 5 stars
expanded Abstract
collapsed Abstract
IBM® Tivoli® Access Manager for e-business (TAMeb) offers single sign-on (SSO) capabilities for deploying a secure solution within IBM WebSphere Portal. WebSphere Portal portals have the capability for creating virtual portals that can be customized independently. This article explains all the steps to bring together these virtual portals and portals under the same security realm with session sharing enabled among them.
Tags: TAMeb, wp-deploy-7, 7.0 deployment scenario
ShowTable of Contents
HideTable of Contents
  • 1 Introduction
    • 1.1 Prerequisites
  • 2 Integrating WebSphere Portal 7.0 and TAMeB 6.1.1
    • 2.1 Integrating WebSphere Portal with a standalone TDS (LDAP)
    • 2.2 Integrating and configuring WebSphere Portal with TAM and WebSEAL
    • 2.3 Making protected/unprotected WebSphere Portal landing pages from WebSEAL using ACL's
    • 2.4 Changing the log-out page of Portal to point to the log-out page of WebSEAL reverse proxy
  • 3 Applying the concept of virtual host junction to Portal and virtual portals
  • 4 Exceptional conditions
  • 5 Conclusion
  • 6 Resources
  • 7 About the authors

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 JavaTM 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

    Property name
    Property description
    standalone.ldap.id
    Specifies unique identifier for the repository within the cell
    standalone.ldap.host
    Host name or IP address of the machine on which TDS is installed
    standalone.ldap.port
    The port number of LDAP default is 389 (non-secure)
    standalone.ldap.binDN
    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
    standalone.ldap.serverId
    Specify the distinguished name for WAS to use when binding to LDAP repository.
    standalone.ldap.realm
    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 **
    standalone.ldap.baseDN
    Base dn ex( o=ibm,c=us)

** 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
    where:
    -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.
 


  • Edit
  • More Actions Show Menu▼


expanded Attachments (0)
collapsed Attachments (0)
Edit the article to add or modify attachments.
expanded Versions (9)
collapsed Versions (9)
Version Comparison     
VersionDateChanged by              Summary of changes
This version (9)Sep 13, 2012, 1:46:55 PMDeAnna Steiner  IBM contributorAdded tags and corrected category
8Feb 6, 2012, 12:16:16 PMReinhard Brosche  IBM contributorCorrected typo uppercase "W" in DWasPassword
7Sep 15, 2011, 3:22:55 PMDave Hay  IBM contributor
6Sep 15, 2011, 2:07:01 PMLeslie Gallo  IBM contributor
5Sep 15, 2011, 1:56:55 PMLeslie Gallo  IBM contributor
3Sep 15, 2011, 1:52:46 PMLeslie Gallo  IBM contributor
2Sep 15, 2011, 1:31:30 PMLeslie Gallo  IBM contributor
1Sep 15, 2011, 1:11:59 PMLeslie Gallo  IBM contributor
1Sep 15, 2011, 1:24:25 PMLeslie Gallo  IBM contributor
expanded Comments (0)
collapsed Comments (0)
Copy and paste this wiki markup to link to this article from another article in this wiki.
Go ElsewhereStay ConnectedHelpAbout
  • IBM Collaboration Solutions wikis
  • IBM developerWorks
  • IBM Software support
  • Twitter LinkIBMSocialBizUX on Twitter
  • FacebookIBMSocialBizUX on Facebook
  • ForumsLotus product forums
  • BlogsIBM Social Business UX blog
  • Community LinkThe Social Lounge
  • Wiki Help
  • Forgot user name/password
  • Wiki design feedback
  • Content feedback
  • About the wiki
  • About IBM
  • Privacy
  • Accessibility
  • IBM Terms of use
  • Wiki terms of use