• 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

• 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

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

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.

• 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

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>

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

./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